Re: Yet another API evolution: multi-valued GrlData

[Guillaume Emont <gemont igalia com>]

On 25/01/2011 08:59, Iago Toral wrote:
>
> 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.
The idea behind prepending, is that it automatically provides backwards
compatibility: the first value of the list would behave exactly like the
only value of a monovalued property
>
>> 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...
Well, I'm not certain it's needed either, but for completeness sake, we
might want to be more complete.
>
>> 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?
I like the idea in Juan's email: allow GrlData instances as GrlData
properties. That way I guess we can relatively easily solve the
serialization issue.
>
> Iago
>
>
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>