Re: Brainstorm: Desktop

["Robert J. Slover" <robert slover Rose-Hulman Edu>]

Ben 'The Con Man' Kahn wrote:
> 
> On Wed, 8 Apr 1998, K. wrote:
> 
> >
> > VFS is an abstraction layer through which the kernel internally interfaces
> > with arbitrary filesystem types. As such it is irrelevent to the current
> > discussion. My apologies if there is a user-level service by the same name
> > which supports eg. HTTP addressing.
> >
 
K.,

I was intending to mean the VFS layer in gmc, not the linux kernel VFS.  
It would be ideal if all unices supported kernel VFS's...but they don't.
The mc VFS allows one to browse into TAR files and into FTP archives.  I
consider it an extension of the Unix 'everything is a file' metaphor.

Way cool, IMHO.

> > The idea of supporting HTTP as a means of accessing configuration
> > information is interesting; for example you could log into a host using a
> > guest account and retrieve your desktop _configuration_ from your usual
> > (now remote) host via HTTP. However a distinction would have to be made
> > between information which is specific to a local host, and information
> > which is host-independent; for example a menu entry which refers to a
> > particular binary (executable) depends on that binary being available on
> > the local system. Images etc. could simply be transferred along with the
> > config info, but this would not be reliable for executables and other
> > system-dependent files.
> 
>         It would seem that FTP is a better choice.  User configurations
> can be password protected (more easily) and they can reside ANYWHERE in a
> user's directory structure.  HTTP is usually confined to a subdirectory
> contained within their directory.
> 

Ben,

You're right, of course.  HTTP was just the first example that came to 
mind.

>         As for troubles with binary files...  Can't this be solved with
> MIME?  (Specify file type, etc.)  Or are you suggesting that a user links
> to Netscape on one machine and has no access on the other?  If so, I can
> think of several solutions.
> 
>         1) Use tools like rpm, locate, whereis, which to find the program
> in question on the local machine.
>         2)If it can't be found, run the program on the remote machine
> (using lbx if available) and export the display.  Why not?
> 
>                                                 -Ben
> 
> ------------------------------------ |\      _,,,--,,_  ,) ----------
> Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
> (212) 924 - 2220                    |,4-  ) )-,_ ) /\
> ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
>  If you love something, write it in C; if it compiles, it is yours;
>                      if it doesn't, it never was.
> 
> --
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.

-- 
------------------------------------------------------------------------
 Robert J. Slover | Admin Sys Mgr | Rose-Hulman Institute of Technology
------------------------------------------------------------------------

 "Yesterday starts tomorrow, Tomorrow starts today.  The problem 
  always seems to be we're picking up the pieces on the ricochet..." 
                                                    -Marillion, "Jigsaw"