Re: Plans for gnome-vfs replacement

[Alexander Larsson <alexl redhat com>]

On Wed, 2006-09-20 at 10:52 +0200, Paolo Borelli wrote:
> Ok, at the risk of sounding a bit picky, can you clarify the following:
> 
> Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha
> scritto:
> > I'd like to call "user document files". These are the kind of files
> > you open, save, or download from the internet to look at. Applications
> > that use these would like highlevel operations that match the kind
> > of operations you use on them, like read-entire-file, save-file,
> > copy-file, etc. 
> > 
> 
> but
> 
> > I've been doing some initial sketching of the glib API, and I've
> > started by introducing base GInputStream and GOutputStream similar to
> > the stream objects in Java and .Net. These have async i/o support and
> > will make the API for reading and writing files nicer and more
> > modern. There is also a GSeekable interface that streams can
> > optionally implement if they support seeking.
> 
> 
> So it's not clear to us if you are aiming at a low-level stream-based
> api or at a higher level document based api. Or maybe both, implementing
> the latter on top of the first.
> 
> Does a stream based api gives us any substantial improvement over the
> current posix-like approach? I may well be wrong but I fear that mapping
> stream operations to things like ftp or http can lead to similar issues
> to the ones we have now...

I'm not sure exactly what you mean by low level streams vs a document
based api. I think its easier to discuss this by giving code examples.
So, lemme show you some of the APIs I have in mind. Remember that these
APIs are work in progress though.

Here is my current GInputStream:

struct _GInputStreamClass
{
  GObjectClass parent_class;

  /* Sync ops: */
  
  gssize   (* read)        (GInputStream *stream,
			    void         *buffer,
			    gsize         count,
			    GError      **error);
  gssize   (* skip)        (GInputStream *stream,
			    gsize         count,
			    GError      **error);
  gboolean (* close)	   (GInputStream *stream,
			    GError      **error);

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

Now, these are not quite posix operation, but they are not totally
unlike it either. I'm not sure how this could be harder to map to ftp or
http than posix? The API is specifically designed to match the
requirements of protocols like these and to avoid the problems that the
posix mapping created (what use would it be otherwise).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a sword-wielding umbrella-wielding librarian on the edge. She's a 
strong-willed impetuous socialite on her way to prison for a murder she didn't 
commit. They fight crime!