Re: File dialogs: Network access



I think this is what you're saying, but to be more specific: The kernel
should not be given the task of handling something so inherently high-level
as abstracting an Internet protocol into a filesystem namespace.  There are
'right ways' to do this.  If nothing else, the kernel could be given a
(better) vfs api and have user-space software interact with those to provide
the extensions.  This would then make it possible to do (as with Samba
mounting):

mount -t vftp 'ftp2.3dgamers.com/pub/mirrors' /mnt/3dgamers-mirrors/

Actually accessing ftp:// and http:// files from the get-go?  That is
interesting, but I think then we have to have Linux change how it handles
its single hierarchy filesystem into something more like UNC or URIs.  I
don't know if that's the 'right thing' or not, but its definately a
fundamental change in how the filesystem is organised on Unix.

----- Original Message -----
From: "Dylan Griffiths" <Dylan_G@bigfoot.com>


> "Michael T. Babcock" wrote:
> >
> > It should access the VFS, whatever that may be provided by.  If I'm not
> > mistaken, there is a gnome-vfs being worked on seperately from gfm, etc.
> > which would be used.  It may understand web sites or ftp directories and
the
> > file-entry dialog simply needs to interface with that, not re-create
this
> > functionality.
>
> Thank you, second voice of reason.  I've said before I'm against adding
FTP
> support, etc, to a common file dialog because it's fundamentally the Wrong
> Place for it.  You say Gnome VFS should handle it, and I think that's an
> interesting solution.  However, I think it'd be better if we just put
hooks
> for it in the kernel and had a userland daemom for the specifics of the
> connection and population of the vfs (like of how userland NFS works).
The
> true VFS is the proper place as it guarantees a consistent view to all
> programs.  But then it's a linux-kernel discussion..






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]