Re: gvfs status report

[nf2 <nf2 scheinwelt at>]

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...

GFileInfo *        g_file_get_info           (GFile                  *file,
                         GFileInfoRequestFlags   requested,
                         const char             *attributes,
                         gboolean                follow_symlinks,
                         GJob           ** job,
                         GError                **error);

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.

typedef enum
{
   VIO_PROGRESS_VALID_NONE = 0,
   VIO_PROGRESS_VALID_TOTAL = 1<<8,
   VIO_PROGRESS_VALID_COUNT = 1<<9,
   VIO_PROGRESS_VALID_BOTH = 1<<8 | 1<<9
} VioProgressValidFields;

typedef enum
{
   VIO_PROGRESS_UNIT_NONE = 0,
   VIO_PROGRESS_UNIT_BYTES = 1<<16,
   VIO_PROGRESS_UNIT_PERCENT = 2<<16,
   VIO_PROGRESS_UNIT_ITEMS = 3<<16  /* for direntries */
} VioProgressUnits;

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;

The other thing is the "shared VFS"  (to be used by  KIO as well). 
Because GIO has a nice pluggable design, a cross-desktop VFS interface 
like i'm trying to create with libvio 
(http://www.scheinwelt.at/~norbertf/devel/vio/)
could also be plugged behind GIO...

regards,
norbert