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
[EMAIL PROTECTED] [EMAIL PROTECTED]
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!
_______________________________________________
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
