Re: Yet another API evolution: multi-valued GrlData
- From: Iago Toral <itoral igalia com>
- To: <grilo-list gnome org>
- Subject: Re: Yet another API evolution: multi-valued GrlData
- Date: Tue, 25 Jan 2011 12:14:52 +0000
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()
>> > _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
> plugin changes, so you want to update the metadata. You should
> 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
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
replace the content of a property by a different value, replace()
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().
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
> another GrlData.
Not sure reusing GrlData is the best way to go.
One thing if the content-type hierarchy (GrlData and subclasses),
represent media objects (that is the semantic here) and another
the individual pieces of correlated information these object may
(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
and mime-type or any other correlation we may find among metadata?
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
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
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
where several properties must be kept together, as thumbnail+size, or
url+mime. For other cases (several artists), the type would be a list
In the case of needing to correlate several keys that doesn't fit in
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);
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
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 :)
] [Thread Prev