Re: Yet another API evolution: multi-valued GrlData

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

On Tue, 2011-01-25 at 10:53 +0000, Iago Toral wrote:
> 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?

Plugin doesn't know if the content in a media must be replaced, kept or
new data appended. Of course, we can set up which behaviour is the
default one. Not sure if "replace" or "append".

In any case, probably replace() seems more suitable for using in the
application side than in plugin side. If a user wants, for any reason,
replace the content of a property by a different value, replace() would
guarantee that replacement is done.

But it's worth to note that replace() is exactly as remove() + add(). I
don't think it hurts having it. But I can not give you an exact
use-case, besides the above one.

> > 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 guess your example is for the case of UPnP, where it can provide
several URIs. In that case, if the content is a video one, then uri +
mime would be a GrlMediaVideo. In fact, if I'm not wrong, a UPnP server
can provide transcoding where only the audio part is shown. In this
case, it would have a list of GrlMediaVideo and GrlMediaAudio.

Of course, using a GrlData as a property only makes sense for the case
where several properties must be kept together, as thumbnail+size, or
url+mime. For other cases (several artists), the type would be a list of
strings.

In the case of needing to correlate several keys that doesn't fit in a
GrlMediaFoo object (still I didn't find the case, but probably there
is), we can always use the generic GrlMedia or, better, GrlData.

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

Of course, that's another approach. But even though, I think the
thumbnail_data type can be a child of GrlData, so we can reuse our own
code.

	J.A.