Re: Plans for gnome-vfs replacement

[Benedikt Meurer <benny xfce org>]

Dan Winship wrote:
>>As a consequence of the stateful model we don't need the stateless
>>properties that URIs has as identifier. To avoid all the problems
>>comming from the use of URIs  we use a much simpler form of
>>identifier. Namely filenames
> 
> We still need to support URIs too at least in some places, because of
> '%u' in .desktop files. If GNOME apps switched to using '%f', then
> konqueror (and old versions of GNOME) wouldn't be able to pass remote
> files to them any more. Likewise, if nautilus/libgnomedesktop didn't
> support using URIs for remote files any more, then they wouldn't be able
> to pass remote files to KDE apps.

I think URI should still be used to refer to resources "from outside"
and to contact the appropriate backends. But internally GFile or
GFilePath objects should be used. That is, the user types in an URI, the
library resolves the URI to a GFile and passes a serialized form of the
GFile to the daemon.

For example, in the Xfce file manager, we use a path object exactly this
way, where an URI like trash:///something-0/file would be resolved to
the following path object:

 path(file) -> path(something-0) -> path(trash root)

using refcounting to keep parents only once if possible. Each path
object has a parent pointer (which is NULL for the root of an URI
scheme), a refcount (excluding the upper bits for the URI scheme) and
the name of the path item.

Determining the parent path or resolving a relative path is easy then,
as you don't need to unescape/escape URIs, but work on path objects with
well defined semantics.

This way, the possible gvfs would still be compatible with the existing
specs (i.e. the thumbnail spec, desktop entry spec, ...), but internally
the applications/backends would use the easier to handle path objects
and don't need to care about escaping/unescaping of URIs.

Not to mention that this would also help to save some memory.

Benedikt