Re: [PATCH 0/9] Multi-valued proposal (WIP)



On Thu, 2011-02-24 at 07:33 +0000, Iago Toral wrote:
> >
> > If we allow plugins defining their own keys, then we must have a way 
> > of
> > having other correlations.
> >
> > Else, let's drop out the possibility of creating new keys in sources.
> 
>  As I explained on jabber, we could have specific API for third party 
>  developers to manage correlations manually in case they need / want to. 
>  It would not be as nice as this, but if that allowed us to have a more 
>  explicit API it could be worth the sacrifice, specially thinking that 
>  the use case for user defined keys with correlations is not something 
>  that I see happening often at all.
> 
>  But anyway, maybe adding some extra utility APIs in GrlMedia* objects 
>  as a way to make some of the most important relations a bit more 
>  explicit is a good balance between both points of view.


Yesterday Iago and I had a meeting to address this WIP, in order to
resolve all concerns and search for ways of making it easier to use.

So finally we agreed to do following changes.


* Merge GrlDataMulti API in GrlData. Thus, GrlData will contain API to
handle multi-valued properties, and will keep the previous API to handle
single-valued API. Actually GrlData will handle everything internally as
multi-valued data, and the single-valued API will work with the first
value of data.

* Keep GrlProperty, but make it a proper class not inheriting from
GrlData. GrlProperty is used to handle single-valued data, and so far it
was inheriting from GrlData because GrlData was precisely designed to
handle single-valued data. But now GrlData will handle multi-valued data
too, so GrlProperty will not inherit any more from it. The API that
GrlProperty will have is basically the same as the one in currently
GrlData.

* Keep correlations as they are, so plugins defining their own keys can
correlate those keys with the current keys.

* Add API in GrlMedia{Audio/Video/Image} to handle the system-defined
keys and correlations, in order to easing its use. This basically means
adding API to do something similar of what Iago proposed about handling
mime, uri, width and size in video content. The same for other content
and keys.


	J.A.
 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]