-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone,
I've read the initial mail on this subject from Alexander Larsson this evening and found it quite uplifting. I've thought for a long time (actually since I've tried to use gnome-vfs the first time) that if might be a good idea to replace this layer by something new. And some time later I saw on freedesktop.org (http://www.freedesktop.org/wiki/Software_2fdvfs) an attempt to generate a standardized library for KDE and GNOME, so I was satisfied and hoped the issue would be solved soon. And I lost track of it, due to other work issues. So today I've read this mail and due to my background in (operating) system design, I thought this is a good idea. (Also I've heard it elsewhere in the gnome community, I don't know where.) And it reminded me at some OS-design lesson some years ago. Put file services in user space. That is what this concept is all about. Alexander mentioned a list of problems the actual system have. Also he provided a some use cases and features the new system must have. At this point I want to add some thoughts to this topic. As pointed out a high-level vfs must support a more object-oriented view to files. I think, we should stop thinking of files in a hierarchical file system and start using the term document or (information) object ... because classical file systems are going south. Things like Beagle, the MacOS search thingy or the database based Windows file system (which will be released just after the hurd, I am absolutely sure) are pointing in a different way of organizing information. We have contact (objects) and mails (objects) which have properties like addresses which are linked to properties of a contact. The same thing you can find in papers, books and all other information like music or movies. In such a context to identify an object is best done by a descriptor handle (id) as A. already pointed out. If you look for instance at the Eclipse Java framework. The files there are represented by an identifier object which could return a URI but in general the API allows to return other location descriptors as well. Which is very useful if you connect the system to a database :-) At least I see a problem with his idea to use gobjects in this implementation. If this service should be cross-desktop-environment then gobject is not such a good idea. KDE uses a different object model (as far as I know they use C++) and it is very unlikely that they want to use gobject in there applications. To solve this (at least in parts) I suggest defining a protocol for the gnome-vfs-daemon which is implementation independent so a KDE client could be implemented without using glib or any other lib out of this context. This implies that using RPCs on gobjects in the daemon wouldn't be a good idea. But RPCs are not faster as other local IPC as such. So this is not a really bad thing. As such I would propose (I know A. already did that more or less) a client side library which knows the necessary high-level operations for data objects (libvfs-client.so), a server (vfs-daemon) with separate processes for each volume or maybe better each data-object (file) it handles. This daemon should have a plug-in interface like gstreamer for different volume types. So it could be compiled without linking it with hundreds of libraries. The rights management should not be the job of the daemon in the way that it have direct access to the keyring but it should be possible to remember security information on a session base. Here is a (somewhat strange) example of a session. - - The user clicks on a share (database located at NSA headquarter) - - The object manager (nautilus) instructs the vfs-daemon to mount the remote share. - - The NSA requests for a retina print so the vfs-daemon asks nautilus for that. - - Nautilus recognizes the reply to be an authentication request and asks the local auth. service to get the information. - - The auth. service (e.g. gnome key manager) instructs the user to look at the retina scanner and returns the information to Nautilus which delivers the information to vfs-daemon. - - The vfs-daemon sends the information directly to the NSA to finish the log on. - - Until the user unmounts the share, the vfs-daemon does everything to keep the share open and accessible for all applications of the user. (session based handling) At this point, I think this shouldn't be all applications because some applications (e-mail client, web browser) run on another security level. So it might be wise to allow only certain applications the access of this share. So all application which want to use the share must know a specific token. Such features are not available on Linux systems (as far as I know) right now, but in the near future this could be important. In reply to Paolo, who mentioned that it is not clear to him if Alexander is aiming for high-level interface and a low-level stream-based system. A Look at the Java file API might help, because I think he is modeling it after this approach. http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html http://java.sun.com/j2se/1.5.0/docs/api/java/io/OutputStream.html But to get a clear picture, we could collect a set of things we want to do on application side with data objects in general (as a first step) and try to distillate a set of methods out of it later. I know this is a rather classic approach to develop software but maybe your interested in it. :-) greetings Reiner p.s. sorry for my bad English, I hope I didn't offend one of you. I just thought it might be a good idea to write something to the subject. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFFYWzMEi33pNDapoRAjEAAJ9/LWOunRjB+wbpTTQzAP2fjBuSyQCfSbFf DoPz0TK4jZpM6m80+0vZ9ak= =L5UG -----END PGP SIGNATURE----- _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
