Re: Yet another API evolution: multi-valued GrlData

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

On Mon, 2011-01-24 at 19:02 +0100, Guillaume Emont 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.

I think it is worth to clarify here that most applications doesn't care
about multivalued properties. Thus, the idea is to keep GrlMedia and
children as they are: they only handle single values. And put the
multivalued api in the GrlData class.


> 
> Then, we would need:
> 
> GList * grl_data_get_all (GrlData *data, GrlKeyID key);
> 

I would like to see a

const GValue *grl_data_get_nth(GrlData *data, GrlKeyID key, guint n)

API.

> 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.
> Some "options" would probably make sense, like a _remove_all() and a
> _replace().
> 

Current GrlData have a property to specify if data can be overwritten or
not. I am not sure if its worth to add a new value for this property,
"append", meaning that data can be appended. And making this the
default.

Thus, user could configure the data to specify if she want to overwrite
current results (meaning she only is interested in one value), or append
results (meaning she is interested in all possible values).


    J.A.