Re: RFC: Operation Options API proposal

[Iago Toral Quiroga <itoral igalia com>]

El mar, 29-03-2011 a las 12:33 +0200, Guillaume Emont escribió:
> On 29/03/2011 10:47, Juan A. Suárez Romero wrote:
> > On Fri, 2011-03-25 at 11:33 +0100, Iago Toral Quiroga wrote:
> >>>> I think the proposal is good. I would start the implementation and
> >> then,
> >>>> if we find issues we may need to adjust some bits.
> >>> Before starting, I think we need to ensure we agree on a few more
> >> points:
> >>>  - inherit from GrlData? (I'd say yes)
> >>
> >> I would not like to inherit from GrlData, same reason I always give
> >> for
> >> that. GrlData was designed to support very different semantics (those
> >> of
> >> the content hierarchy: GrlMedia, etc) and here we would be using it
> >> for
> >> a concept that is semantically different (the operation caps and
> >> options). If we want to reuse GrlData I'd rather use composition than
> >> inheritance, but even in that case I'd probably just use a GHashTable
> >> and leave GrlData alone. 
> > 
> > 
> > I guess that Guillaume already went with GHashTable, but to give more
> > feedback in order to understand if GrlData fits or not (besides the
> > semantic reasons Iago gave above):
> > 
> > * In GrlData, the key must be a GrlKey, and must be registered on the
> > plugin registry.
> > 
> > * GrlData is designed to work with multi-valued elements.
> > 
> > Pretty sure the kind of data to be stored in the caps/options are not
> > the one that GrlData handles.
> > 
> > In fact, all those reasons were the ones that made me forget about using
> > GrlData to implement GrlConfig.
> 
> Actually, I'm trying to go with GData in the end, mainly for semantic
> reasons:
>  - GrlData needs registered keys, and we don't want to mix data keys and
> caps or options keys
>  - GHashTable is meant for a dictionary of (key, value) where key is of
> a given type and value is of a given type (the value destroy func you
> give to g_hash_table_new_full() is for all values), which means all
> values need to be of the same type, meaning we would have to use GValues
> which I find a bit heavy to program with
>  - GData is meant for a dictionary of (key, value) where key is a string
> (or, well, a GQuark made out of it), and value is of any type, with a
> destroy function given individually for each valye. I think this fits
> more the type-wise heterogeneous data we want to store.
> 
> If at some point experience shows GData is too slow (it's implemented
> with a linked list), we can still switch to GHashTable + GValue, but
> that would make the code a bit more complicated, especially since the
> stuff we would store would need to be GType registered (or use GBoxed).
> Just passing the value and a destructor sounds much simpler to me.

I think the risk with this approach is not performance but semantics.
The problem that GrlData tries to solve is not the same we try to solve
with GrlOptions or GrlCaps. GrlData is there to solve the needs of the
content hierarchy (GrlMedia, GrlAudio, etc) and it may need to be
changed in the future to fit those needs, rendering it not so useful for
the case of GrlOptions or GrlCaps any more.

Iago