Re: RFC: Operation Options API proposal

["Juan A." Suárez Romero <jasuarez igalia com>]

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.

	J.A.