Re: Yet another API evolution: multi-valued GrlData

[Guillaume Emont <gemont igalia com>]

On 25/01/2011 10:21, Juan A. Suárez Romero wrote:
> 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.
+1
I like that idea much more than adding another property that would
actually apply on an existing property, and not on the media itself
(e.g. thumbnail-sizes would relate to thumbnails and not to the media
itself directly).
> 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.
>
>
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>