Re: gvfs status report

[Alexander Larsson <alexl redhat com>]

On Mon, 2007-02-19 at 17:27 +0100, nf2 wrote:
> Alexander Larsson wrote:
> > The last month or so I've continued my work on a gnome-vfs replacement
> > called gvfs. Its still nowhere near finished, but its getting to a
> > state where it might be interesting for people to look at and give
> > some feedback. So, here is a writeup on the current design and
> > codebase.
> >
> > If you haven't read my previous mail about the shortcomings of
> > gnome-vfs before I'd recommend you at least scan it before
> > continuing:
> > http://www.mail-archive.com/gnome-vfs-list gnome org/msg00899.html
> >
> > The code is currently availible in a git repository at:
> > http://www.gnome.org/~alexl/git/gvfs.git
> >
> > The gvfs code consists of three parts, a library "gio" which has the
> > API that applications use, a set of daemons handling access to various
> > file resources (only smb implemented atm), and a dynamic module that
> > (optionally) gets loaded into gio that communicates with said daemons.
> >
> >   
> Just a some ideas: I wonder if i would be nice to have some kind of 
> client side interface to 'jobs' - for instance to receive progress 
> callbacks. Even operations like 'g_file_get_info' can take long - for 
> instance if they have been queued by the daemon. Perhaps instead of the 
> GCancelable object, a GJob object could be registered with the 
> operations (or be returned by operations). GJob could then be used for 
> cancelation as well...

A stat() operation can take a long time too (say on NFS). But creating a
(probably heavyweight) job for each stat operation doesn't sound all
that useful to me. I think job tracking (when needed) should happen on a
higher level than the pure i/o operation level. All sorts of separate
i/o can be part of a single job (as the user sees it), and a higher
level API for job tracking would make it possible to track all such
different kinds of jobs in one place (i.e. a Mathusalem style gui).

> g_job_register_progressHandler(GJob * job, void 
> (*progressHandler)(count, total, fields, units, stage));
> g_job_register_cancelable(GJob * job, GCancelable *cancelable);
> 
> For instance in my "vio" thingie any operation can send progress 
> messages, which have a 'count', a 'total', 'valid fields', 'progress 
> units' and 'stage' fields. This could easily be displayed in a standard 
> progress widget (which might also have a "Cancel" button) to give the 
> user more info whats happening behind the scenes.

All the i/o operations availible in gvfs right now are lowlevel "atoms"
really, and don't really have a use for progress info. However, when
slightly higher level operations like file copy are added, some form of
progress info will be needed.

> typedef enum
> {
>     VIO_STAGE_UNKNOWN = 0,
>     VIO_STAGE_AUTHENTICATION = 1,
>     VIO_STAGE_CONNECTING = 2,
>     VIO_STAGE_RECONNECTING = 3,
>     VIO_STAGE_DOWNLOADING = 4,
>     VIO_STAGE_UPLOADING = 5,
>     VIO_STAGE_WAITING = 6,
>     VIO_STAGE_COPYING = 7,
>     VIO_STAGE_READING_DIR = 8,
>     VIO_STAGE_QUEUED = 9,
>     VIO_STAGE_MOUNTING = 10
> } VioProgressStage;

Most of these states are for a stateless system (like gnome-vfs) where
any sort of operation (like authentication or connection) can happen on
any i/o operation (with the corresponding complexities). gvfs is
stateful, so such operations would only happen during mounting. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a shy shark-wrestling vampire hunter looking for a cure to the poison 
coursing through his veins. She's a man-hating belly-dancing pearl diver from 
Mars. They fight crime!