Re: vfs Was: RSS/RDF Aggregator

[Helge Hess]

ibotty wrote:
> > What I heard against VFS was mostly about the visual representation for
> > the file manager : ie, that it could leads to replace GWorkspace.app UI
> > with a browser-metaphor UI. The other thing was that theorically VFS
> > shouldn't be the GNUstep job, but the kernel job. Problem is that GNUstep
> > is theorically multiplatform ...
> yes, the ultimate goal is to have the kernel manage all vfs's. but this is
> not going to happen very soon. i have a patch against dragonflybsd, that
> provides imap support at the kernel level. (yes, imap is one of my toys)
> somewhen most kernels will transfer filesystems to userspace (dragonfly
> sooner, others later), then, a (broad) vfs on kernel-level is possible.
> maybe not for gnustep, as its focus is multi-platform.

Well, personally I think this makes no sense. You would need new, async 
API for this or use threads. And you would need to extend the Unix user 
model etc.
The idea is pretty, but in practice this won't work out because 
protocols like IMAP4 or WebDAV do *not* work like a traditional 
filesystem. While they have similiar "API", they have very different 
access characteristics, eg usually high latency, which isn't covered by 
the Unix API.
This issue is very much apparent in MacOSX where the native WebDAV and 
FTP really break the Finder badly (and this time the Finder isn't guilty 
;-).

> > My opinion here is that I agree with the idea that GWorkspace shouldn't
> > be the placeholder for all URL (as konqueror is). But in the same time,
> > it would be great to have a unified method to /open/ URLs with the right
> > application ! 
> this is mimetype-handling, isn't it. this is unrelated to vfs.
> yes, i understand, that this was, what the thread was about, but
> nevertheless.

Well, MIME-Type handling isn't completely unrelated to VFS since MIME 
types do depend on the "virtual" filesystem, eg IMAP4 or WebDAV. Eg 
Workspace.app would usually construct the MIME type based on the 
extension for local filesystems. But on WebDAV it should use the 
content-type property of the file and on IMAP4 the content-type header 
of the message.
Another reason why (high-level) VFS in kernel su**, the Unix API can't 
really deal with MIME-types and various other types of meta data (eg 
display-name).

One other point, which might have been the initial issue of Nicolas: it 
doesn't make sense to "permanently mount" any and each URL being 
accessed in the system as this usually only is relevant in the current 
application context (eg the RSS reader ;-)
So Workspace.app shouldn't "show" the whole Internet. But it would be 
very useful to open a Workspace viewer on a WebDAV or IMAP4 or Samba URL 
- just like in Nautilus (which is slow and doesn't look as good as 
Workspace, but does the actual task pretty well).

Oh, BTW: those KIO slaves are only "interesting" for keeping the app 
single threaded, which is important, IMHO. Just fork off a slave dealing 
with higher-level VFS and use async-IO for notifying the actual API.

regards,
  Helge