Re: Plans for gnome-vfs replacement

[Alexander Larsson <alexl redhat com>]

On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:
> On Wed, 20 Sep 2006, Alexander Larsson wrote:
> 
> > On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
> >>>
> >>>> 2) What is the signature of GDestroyNotify ?
> >>>
> >>> Its already in gtypes.h:
> >>> typedef void            (*GDestroyNotify)       (gpointer       data);
> >>
> >> ah. I forgot about this. Don't you think it might make sense for ease of
> >> use to add a void *buffer arg and a GOutputStream * arg to the destroy
> >> notification ?
> >
> > Nah, In typical real world cases these would already be in the user_data
> > object. Say if you're reading a whole file async. It feels better to
> > keep to the standard glib destroy notifier handling.
> 
> i have to agree with Mathieu here. not passing the original object handle
> forces the user to keep tedious etxra data structures around.
> imagine:
> struct UserObject {
>    GOutputStream *stream1;
>    GOutputStream *stream2;
> };
> 
> naturally, you'd pass UserObject* as gpointer data to the stream.
> if your notifiers don't also contain the GOutputStream* handle though,
> the user can't clearly identify stream1 vs. stream2 though, so he'd have to
> resort to creating helper structures:
> struct UserObjectOutputStreamCallbackData {
>    UserObject    *user_object;
>    GOutputStream *stream:
> };
> and allocate/pass/free this instead.

The actual operation callback for an async operation does of course pass
both the stream and the user data. And it is always called, even on
cancellation, so the destroy notifier isn't required. The destroy
notifier is more of an extra freebie to make it simple to add a g_free
or g_object_unref to free the user object. For a more complicated
multi-stream setup I think you'd do the handling in the operation
callbacks.

Also, In your example above the extra structure isn't needed. One would
just use different destroy notifiers for the two streams.

> (not providing GOutputStream, but just data, would be a bit like eliminating
> the instance argument from signal handlers and force people to pass it along
> as part of the user_data passed in to g_signal_connect() ;)

I don't think so. I.e. for an aync read the callback would look like:

typedef void (*GAsyncReadCallback)  (GInputStream *stream,
				     void              *buffer,
				     gsize              count_requested,
				     gsize              count_read,
				     gpointer           data,
				     GError            *error);

This callback is similar to the signal handler. The destroy notifier is
just gravy on top of it.

If we're stretching our comparisons a bit here it would be more like
having the GDestroyNotifier called for a hashtable entry also pass a
pointer to the hashtable so that you can destroy the entry differently
depending on which hashtable it was in. :)



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely drug-addicted Green Beret on the hunt for the last specimen of a 
great and near-mythical creature. She's a radical mutant advertising executive 
with the soul of a mighty warrior. They fight crime!