Re: Plans for gnome-vfs replacement

[Reiner Jung <prefec2 web de>]

-----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-----