Re: Yet another API evolution: multi-valued GrlData

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

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

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 :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]