Re: Yet another API evolution: multi-valued GrlData

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

On Tue, 2011-01-25 at 07:59 +0000, Iago Toral wrote:
> > The methods grl_data_set*() would change meaning, in that they will
> > prepend a value to the list of value. The "old" getters will get the
> > first value of the list.
> 
>  just a nitpick, but maybe they should actually append instead of 
>  prepend. I guess many times only the first value will be used by apps 
>  and in these cases, I would like the first value in the list to be the 
>  first value provided by the service, which, I guess, could be the most 
>  significant in many situations.

Yep, I agree here.

> > Some "options" would probably make sense, like a _remove_all() and a
> > _replace().
> 
>  Can't figure out a good use case for a replace() myself...

A very simple use case is when you have a GrlData, and the content in
plugin changes, so you want to update the metadata. You should specify
you want to replace the current metadata for the new one.

Of course, other approach is removing all values and then querying again
the source.

> > Then, for instance for the thumbnail case, a user that only want the
> > default thumbnail would do a simple:
> >   thumbnail = grl_media_get_thumbnail (media);
> > But the use who want to chose among all those available would access 
> > two
> > keys: thumbnail and thumbnail-size, here is a very basic (and maybe
> > unpractical) example of use:
> >   GList *thumbnails = grl_data_get_all (GRL_DATA (media),
> > GRL_METADATA_KEY_THUMBNAIL);
> >   GList *sizes = grl_data_get_all (GRL_DATA (media),
> > GRL_METADATA_KEY_THUMBNAIL_SIZE);
> >   gchar *thumbnail_url = g_list_nth_data (thumbnails, g_list_index
> > (sizes, 320*200))
> >
> > Thoughts? Ideas? Alternatives?
> 
>  I think the proposal is ok for the most part.
> 
>  The part that deals with multiple correlated properties (like multiple 
>  thumbnails + their sizes) is not very elegant, but as we discussed in 
>  the past, other options would include creating complex data types 
>  (custom structs) for some properties (thumbnails in this case would have 
>  two fields one for the thumbnail uri and another one for its size) and 
>  that could complicate other parts of the framework (data serialization 
>  would be one example but I guess there could be others).
> 
>  The same problems exists when various versions of the same resource are 
>  available (for example for UPnP servers with transcoding support), in 
>  which we have multiple URI,mime pairs that are correlated.
> 
>  I would like to give this option (complex data types) a deep 
>  evaluation, detect what problems we would have with that and evaluate if 
>  these problems raise a real complicationor not, so we are sure we are 
>  doing the best decision.
> 
>  what are your thoughts on this?


This proposal is very easy to implement, and fulfills the requirements
about why we need to have multivalued properties.

But I agree also that this kind of correlations is not very elegant.
Plugins must understand and well-implement it in order to avoid
inconsistencies in the results (a plugin inserting only the thumbnail
but not its size would break the data).

A different approach consists of reusing what we already have to
implement solve this problem: the value of a GrlData property can be
another GrlData.

Let me explain with an example. A thumbnail is actually an image. If the
thumbnail were a media on its own, we would have a GrlMediaImage with
its own properties: url, size, so forth.

So one idea is to specify that "thumbnail" property is not a string, but
a GrlMedia on its own. Thus, we would store in the thumbnail property a
list of GrlMediaImages.

Of course, this is a rough idea, and we would need think carefully about
it. Mainly because I think that going with it, probably means that all
applications should be aware that data can be multivalued. In this case,
we would provide required API so applications would access data as if it
were single-valued.

In any case, going with this proposal or not, we can think about using
other alternatives. We would need to know the cases where multivalued
properties are a must (or desirable).

	J.A.