[Nautilus-list] Re: [GNOME VFS] Re: More GNOME VFS abstraction

[Ettore Perazzoli <ettore helixcode com>]

Hello Darin,

    Darin> I do think that this is a better design that what's in
    Darin> GNOME VFS right now.  But after I read this and thought
    Darin> about it for a while I got really frustrated. There's a lot
    Darin> of work required to get GNOME VFS into shape:

  I know that.  That's why we are at 0.1, not 1.0.  And I think most
of the problems you are listing have been known for a long time.

  I wish I could spend more time on this, but my work on
Evolution/GtkHTML did not let me do more than what I have done so far.
Although, I must say, I definitely want to contribute more to GNOME
VFS and Nautilus.

    Darin> These are only the things I can think of "off the top of my
    Darin> head" (and some are currently reflected in Bugzilla at
    Darin> Eazel). These need to be taken care of before GNOME VFS is
    Darin> ready.

  Of course.

    Darin> I'm a bit annoyed that we're considering a good, but
    Darin> unnecessary, change to the GNOME VFS API when we are going
    Darin> to have trouble getting it into shape with the deadline we
    Darin> already have.

  OK, the basic point is that I think we do need this kind of generic
extensibility somewhere in the shell or GNOME VFS.  And it's better to
do it now, than later.

    Darin> I also don't like doing this design without concrete
    Darin> specific examples. What are these additional attributes
    Darin> that other objects might have. A list of some of these
    Darin> would help me better evaluate how good an idea this really
    Darin> is.

  It pretty much depends on the file system.  For example, a "trash"
file system could have a property for the original position and date
of the file.  A ZIP file system might hold the MD5 sum as stored in
the file's directory.  A printer spooler directory might have
information such as the number of pages pending.  Other file systems
might support a special kind of ACLs.  And so on...

  But then, let me reverse the question, as I am afraid I am not in
sync with the design ideas behind Nautilus anymore.  How is Nautilus
going to deal with the representation of the overall system?  Are we
going to have a "My Computer" -like folder?  Are we going to have a
trash with different properties from those of a normal directories?
Are we going to have other special folders such as "My Network", a
"Synchronization" folder and stuff like that?  If so, how are these
going to be implemented?

    Darin> This brings up a good design point. I think it's important
    Darin> to be able to interrogate an object and find out what
    Darin> operations are allowed. For example, with the current
    Darin> interface, you can only find out that you can't write to an
    Darin> http: URI by trying it and getting the UNSUPPORTED error
    Darin> message.

  That's indeed limited and should be fixed.  I think there should be
a query mechanism for operations too.

    Darin> What's the point of enumerating all the properties? If you
    Darin> don't know what they mean, this is only useful

  When you display the directory in the file manager, you do want to
know what properties you have and show them to the user.

    Darin> I'd like to see these property IDs have namespaces so
    Darin> properties defined by one file system module can't conflict
    Darin> with another.

  You don't need namespaces, if the property IDs are only valid within
a file system.  (Except for the basic ones, that are known in advance
and are shared across file systems.)

    Darin> When defining something like this, please don't smush words
    Darin> together. I'd much prefer
    Darin> GNOME_VFS_PROPERTY_MODIFICATION_DATE.

  OK, but I don't think this is relevant now.  :-)

    Darin>     1) A GnomeVFSPropertyBag is a holder for a bunch of
    Darin> property values. It has no knowledge of where those values
    Darin> came from. It's job is simply to be a flexible alternative
    Darin> to something like struct that can hold tagged values of
    Darin> different types.

    Darin>     2) A GnomeVFSPropertyBag has some connection to the
    Darin> original file. It can be used to get additional information
    Darin> about the same file.

    Darin> I prefer approach #1.

  Me too.

    Darin> It would simplify things if we could just ignore metadata
    Darin> when implementing GNOME VFS, but lets consider it for a
    Darin> second anyway. The main difference between the properties
    Darin> offered by the file systems and metadata is that the
    Darin> metadata is held by the file system on behalf of the
    Darin> application and is thus open ended. I'm not sure this
    Darin> justifies using an entirely different API to manipulate it.

  I think it does, because this is an efficient way to retrieve/modify
properties that belong to the file system, so you don't have to care
about things such as concurrent access and encoding of the metadata.
It's done at backend level, while metadata would be done at GNOME VFS
or application level.

    Darin> I can imagine an attribute for a directory that expressed
    Darin> the size of the directory and all the files inside it,
    Darin> recursively. For many Unix file systems this doesn't even
    Darin> have a clear definition due to the existence of
    Darin> links/inodes. And it will take a long time to compute. But
    Darin> for other file systems, this is both useful and fast to
    Darin> compute.

  Interesting point.  I think we could just avoid making the property
available on the file systems for which this computation is slow.  As
I said, this is supposed to represent native properties of a file
system, things that the backend can compute trivially.

    Darin> I agree that this is the trickiest part of the API. The
    Darin> best thing would be if it could use something that's
    Darin> suitable for GLib or Gtk or other parts of GNOME. I see
    Darin> nothing file-system-specific about this bag of
    Darin> properties. It's just a fancy struct, in my opinion.

  I agree with you.  But the problem is that having something added to
GLib/GTK+ is a big pain, so I wouldn't rely on it.  The only thing we
can do is writing it in a way that is generic enough, and hoping for
later integration into the rest of GNOME as a stand-alone thing.

    Darin> Unlike Pavel, I'm not sure that we'd keep the property bags
    Darin> around after the fact for each file in a directory
    Darin> display. We might instead extract the values we're
    Darin> interested in and keep them in a simpler and thus more
    Darin> efficient data structure.

  I agree here too.

    Darin> I'd like to make what we have work better before adding
    Darin> more stuff.

  Surely we need to fix the broken stuff, but as this is going to
change the way back-ends and library clients will work in a
non-trivial way, I think it's better to do this sooner than later.

    [Bonobo-based extensibility of dialogs etc.]
    Darin> I completely agree that we want this kind of extensibility
    Darin> in Nautilus, but I don't know how or if GNOME VFS should be
    Darin> involved. In the extreme case, you could imagine file
    Darin> systems where there were not only lots of additional object
    Darin> attributes, but also many different object operations, all
    Darin> accessible through the VFS. But these operations would all
    Darin> have to have very simple or nonexistent user interfaces if
    Darin> we expect to be able to do them at the GNOME VFS level.

  I brought this point up myself a few times already, and I agree with
your perplexities.

  Originally (read: gnome-fm), I had planned a two-way approach to the
problem of extending the shell namespace through special folders and
files.  On one hand, I had GNOME VFS as the standard way to access
things that look enough like Unix files.  On the other hand, I had
planned to extend the shell through Bonobo interfaces and controls, in
a way that was similiar to that of Microsoft Shell Namespace
Extensions.  This second mechanism was the GUI-aware and most abstract
one: the shell woul have not known anything about the objects in the
folder, and would have just delegated the component handling the
folder to deal with properties, operations and so on.

  (Nautilus happened when I was about to write my draft implementation
for that in gnome-fm, then I got swamped with Helix stuff to do and
the idea was somewhat dropped in Nautilus.)

  Maciej seems to think that this was a bad idea, because it would
make the design less clean.  I am not convinced, but he has some good
points, so at GUADEC we basically agreed to come up with some kind of
GNOME VFS extension mechanism that would make GUI aware extension
possible while keeping the idea of using GNOME VFS as the unique
underlying engine.

  Basically, my proposal is a step in that direction.  If I were the
main Nautilus author now, I would probably just stick to my original
idea, which is simplier.

  Anyway, a way to hook up special GUI-aware file operations to the
VFS could be to add a special property listing the available
operations, with an associated component ID to fire it up through
CORBA/Bonobo.  This means that, while VFS would not have to be
GUI/Bonobo-aware, it would provide the shell with the hooks to
implement this is in a GUI-aware way.

  I am not convinced of this design myself, but I thought using GNOME
VFS more was the approach Eazel wanted to follow...

  Maciej?

    Darin> There are two issues here. First, the "/" is not really a
    Darin> reserved character in GNOME VFS.

  Huh?  The "/" in Unix is the path separator.  So if we want to quote
that, we need a quoting mechanism.  And the quoting mechanism would
conceptually separate the actual path from the displayed name
("caption"?), which is basically what I am advocating.

    Darin> I am worried a bit about working to hard to make custom UI
    Darin> by just creating a GNOME VFS module. For example, you will
    Darin> also want to customize the display of the control panel in
    Darin> other ways. I'm not sure that the virtual file system model
    Darin> can express things well enough to make it worthwhile to try
    Darin> to express the control panel as a file system.

  I don't know what you Eazel guys think, but I do personally like the
way Windows does that.  The user just has a folder with objects, just
like the rest of the system, and she can move them around, sort them,
right-click them, double-click them, exactly like all the other things
in her system.

  Actually, the way I want to extend GNOME VFS is no longer a "file
system" abstraction.  It's an "objects in folders" abstraction.  I
think the basic point is whether we want this to be in GNOME VFS or
into the shell as I originally planned.

    Darin> We may be able to make the control panel VFS work well
    Darin> enough for "ls", but probably not well enough for any
    Darin> program that doesn't know it's a control panel URI to
    Darin> actually manipulate the control panel settings.

  That's why I initially advocated doing this at shell-level instead
of GNOME VFS-level, indeed.  But still, I would like the Control Panel
to behave like a normal folder.

-- 
Ettore