Re: RFC: Operation Options API proposal

[Guillaume Emont <gemont igalia com>]

On 29/03/2011 13:02, Iago Toral Quiroga wrote:
> 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.

I agree with you on the semantic issues with GrlData, that is why I was
talking about using GData[1] (with two letters less, from GLib), which
seems to have the right semantics, but might not be as efficient as a
GHashTable.

[1] http://library.gnome.org/devel/glib/2.28/glib-Keyed-Data-Lists.html

> 
> Iago
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list