Re: Plans for gnome-vfs replacement

[Mathieu Lacage <Mathieu Lacage sophia inria fr>]

On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:

> Here is my current GInputStream:

very nice. Comments below.

> 
> struct _GInputStreamClass
> {
>   GObjectClass parent_class;
> 
>   /* Sync ops: */
>   

Do you dislike the idea of moving the GError as a member of the
GInputStream instance ?

>   gssize   (* read)        (GInputStream *stream,
> 			    void         *buffer,
> 			    gsize         count,
> 			    GError      **error);
>   gssize   (* skip)        (GInputStream *stream,
> 			    gsize         count,
> 			    GError      **error);
>   gboolean (* close)	   (GInputStream *stream,
> 			    GError      **error);
> 

1) Don't you think it might make sense to also add an io priority arg to
the sync functions ?
2) What is the signature of GDestroyNotify ?
3) Do you expect GDestroyNotify to be invoked afer GAsyncReadCallback
during normal successful reads ?

>   /* Async ops: (optional in derived classes) */
>   guint    (* read_async)  (GInputStream  *stream,
> 			    void               *buffer,
> 			    gsize               count,
> 			    int                 io_priority,
> 			    GMainContext       *context,
> 			    GAsyncReadCallback  callback,
> 			    gpointer            data,
> 			    GDestroyNotify      notify);
>   guint    (* close_async) (GInputStream  *stream,
> 			    GMainContext       *context,
> 			    GAsyncCloseCallback callback,
> 			    gpointer            data,
> 			    GDestroyNotify      notify);
>   void     (* cancel)      (GInputStream  *stream,
> 			    guint               tag);
> }
> 
> GInputStream objects can optionally also implement the GSeekable
> interface to support seeking and truncating. This is your basic
> syncronous read API with an addition of some async calls. If a derived
> class doesn't implement the async calls the baseclass will emulate them
> using threads (similar to how gnome-vfs works now). GOutputStream is
> similar, without the skip method, but with a flush method added.
> 
> These are then used in the vfs to handle document reading. The API for
> reading a file is simple, it would be something like:
> GInputStream *g_file_read(GFile *file);
> 
> For writing a file things are a bit more complex. An example API set
> could be:
> GOutputStream *g_file_append_to (GFile *file);
> GOutputStream *g_file_create    (GFile *file);
> GOutputStream *g_file_replace   (GFile *file,
> 		                 time_t mtime_of_old_version, /* optional */
> 	                         char *backup_name /* optional */ );
> 
> Error handling on open is handled by the stream (to avoid forcing a sync
> open). The replace operation does the optimal handling of atomic replace
> and backup for the specific backend.

Are you saying that _append and _create would not be synchronous
operations ? If so, what happens if I attempt a sync read after an async
_append and the async _append fails ? Will the sync read fail and report
the error of the async _append ? Is there a way to schedule an open
barrier ? that is, be notified upon open completion with the operation
status ?

Mathieu
--