Re: Yet another API evolution: multi-valued GrlData

[Iago Toral <itoral igalia com>]

On Tue, 25 Jan 2011 10:21:00 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> On Tue, 2011-01-25 at 07:59 +0000, Iago Toral wrote:
(...)
> > > 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.

Shouldn't that be the default behaviour?

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

Not sure reusing GrlData is the best way to go.

One thing if the content-type hierarchy (GrlData and subclasses), that 
represent media objects (that is the semantic here) and another thing is 
the individual pieces of correlated information these object may include 
(and which do not have to be media items by themselves).

Example: GrlImage works well for the thumbnail data, because a 
thumbnail is a media item, but what about the correlation between URI 
and mime-type or any other correlation we may find among metadata? I 
think the semantics are not the same and we should not mix them.

I would like devs be able to do something like:

thumbnail_data = grl_thumbnail_data_new (uri, size);
uri_data = grl_uri_data_new (uri, mime)
grl_media_set_thumbnail (media, thumbnail_data);
grl_media_set_uri (media, uri_data);

and then:

thumb_data = grl_data_get_thumbnail (data);

uri_data = grl_data_get_uri (data);
mime = grl_uri_data_get_mime (uri_data);
uri =  grl_uri_data_get_uri (uri_data);
...

Iago