Re: GVfs status report

[<tpgww onepost net>]

Hello all

I've been thinking about a file-manager interface to gvfs (more particularly, gio) to help flush out any "devil-in-detail" issues at this  stage of gvfs development. Found some, of course. Some are matters that might have an impact on gvfs design, others are just things for which (sans API docs) I'd welcome some explanation.

And Alex, you did request, so, here goes.

You mention that that the API is close to final now. What will happen to non-superseded bits of gnome-vfs? I'm thinking of things like the URI management functions, maybe the mime-management ones. Glib ?

Will the the gnome-vfs approach to "compound" URI's (IMHO "fragmented URI" doesn't sound too good) be retained?

A while back, there were messages here about URI syntax. Has that been resolved ? e.g. between
   ftp://user pw host/path/archive#gzip:#tar:[....]
 (essentially a series of instructions for processing)
   ftp://user pw host/path#tgz://archive[....]
 (easier for detecting and re-using mounted items, and parsing details in fragments)

I presume that gvfs mountpoints are the respective namespace roots, i.e. a point does not include any initially-opened path there.

Has it been resolved whether and how mountpoints would be represented in the native fs namespace ?

What will a mountpoint, in ~/.mounts or whereever, look like to anything that doesn't know what it really is? What would happen upon e.g. `ls mountpoint` ? What would happen if a virtual item is overwritten by a native file, or an additional native file is copied to some path in a mountpoint ?

Is it correct that a complex mountpoint will be [un]mounted via a single request, so apps don't need to separately request each item in the chain of points?

Is it correct that any point in such a chain can be independently used after such mounting ?

IIRC gnome-vfs can't handle URI details (e.g. password) in any fragment, though some archives do have a password. What will apply in gvfs ?

There are two sorts of gvfs mount functions ATM. I'm guessing that one sort is for media that need to be physically [un]mounted, and probably this applies only to local devices/media. The other sort, I suppose, is for logical mounting of remote sites, archives etc. There does not seem to be an unmount API for the latter type - do we never expect to unmount them?

A while back there was some discussion about a per-user? file, in effect a virtual fstab for gvfs mountpoints. Would that be stateful in the sense of replicating mtab as well ? How would passwords be managed ?

Presuming that unmounting will be appropriate sometimes, and that different apps or instances of same app might independently mount and unmount, is there a ref counting process for mountpoints ?

What encoding should be used for paths and names in gvfs mountpoints ? e.g. an archive could have been created anywhere.
Should there be a point-specific encoding property that can be interrogated by an app, or should apps manage such encoding themselves ?
What encoding for strings e.g. default user in mount-related callbacks ?

A couple of mount-related callbacks have no user-data parameter, it would be friendly to provide that instead of the app having to set/get data in order to interface with mount-related data.

What happens when some relevant daemon goes AWOL ? Will gio operations simply (hopefully not silently) fail ?

There's a flag for traversing [or not] links when getting or setting properties of a GFile. I don't see the same thing for checking whether it's possible to set properties.

Do apps _really_ need to use string-form property names for getting and setting properties ? Seems clunky in userland. The lib could translate between string and something shorter, if strings are needed for daemon communication ?

If an app requests a property in a form other than which it's stored (i.e. an integer of a different size) does the request fail, or is it simply cast before return ?

Is it correct that the generic approach for renaming is to change name property, i.e. not a NIXish move. 

Can ACL's and other extended attributes be checked and set ?

In the same vein as the test for modifiable properties of an item, it might sometimes be desirable to check operation validity (e.g. does this method support deletion), as an alternative to just trying and failing. I'm thinking of a case where alternative handlers are pre-assigned to operations. Not very likely, I guess.

Is file- and directory-change-monitoring only for native items ATM? If so, what's the outlook for this changing ?


PHEW !!

Regards
Tom