[Top][All Lists]

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

Re: vfs Was: RSS/RDF Aggregator

From: Helge Hess
Subject: Re: vfs Was: RSS/RDF Aggregator
Date: Thu, 23 Oct 2003 01:24:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]