Re: Yet another API evolution: multi-valued GrlData

[Iago Toral <itoral igalia com>]

On Tue, 25 Jan 2011 12:53:17 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> 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.

So what would a normal "set" do if it does not replace?

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

As I said before, IMHO, that is semantically incorrect. The video item 
you are representing is only one, that happens to have various uris (and 
hence mimes) associated. All the other metadata of GrlMediaVideo is the 
same for all the versions and makes no sense to have that for each URI 
(author, date, etc). We are mixing things here.
URIs do not have video/audio/image nature, they are URIs and only have 
a mime-type associated. The actual item they point to is the one that 
has that nature and that is represented by the top GrlMediaVideo object.

Actually, it is pretty absurd situation, we would be representing a 
Video content with a GrlMediaVideo object which URI is another 
GrlMediaVideo object!! and they are two different things (one id the 
video item itself, the other its URI data)... I think my point is pretty 
obvious.

I repeat: check the semantics. We did not create the content hierarchy 
to represent this and I think mixing things is a mistake that we will 
regret later.

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

Reuse what? a set/get method? :) Our GrlData is nothing more than a 
bunch of get/set ops wrapping a hashtable...

And btw, we already had this conversation once for grlconfig, there I 
was saying already that just because they both look alike, since they 
did not have the same semantics we should not use the same code and make 
grl-config be a subclass of grl-data, and you know what has happened :). 
So let's not repeat the same mistakes more than once, please :)

Iago