Re: Yet another API evolution: multi-valued GrlData

[Iago Toral <itoral igalia com>]

On Mon, 24 Jan 2011 19:02:32 +0100, Guillaume Emont <gemont igalia com> 
wrote:
> Rationale: some fields might need to have several values, such as
> thumbnails that can be provided in several resolutions, or 
> description
> provided in several languages, also, there could be more than one 
> author
> to a media.
>
> API Proposal:
>
> The idea would be to have key-(value list) pairs instead of key-value
> pairs. That idea can also be seen in ocaml's Hashtbl:
> http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.html
>
> The present API would work by only addressing the first value of the 
> list.
>
> Then, we would need:
>
> GList * grl_data_get_all (GrlData *data, GrlKeyID key);
>
> Return a GList of all the GValue that have been set for key. The list
> should be freed by the caller, but its content remain owned by the
> GrlData object and should not be modified
>
> 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.

> 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...

> 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?

Iago