GNOME.org
 

Re: [PATCH 0/9] Multi-valued proposal (WIP)
On Wed, 23 Feb 2011 09:51:23 +0100, "Juan A." Suárez Romero <jasuarez igalia com> wrote: 
(...)
One thing that I don't like is GrlDataMulti: I don't see a good reason 
 to have this, it does not solve any problem and introduces a new
object/concept making things slightly more difficult for no good reason.
When we discussed this topic in the past we always talked about adding additional API to GrlData and making it handle single and multi valued 
 data transparently, not about subclassing it, and that is still the
 approach I think we should follow. Let's keep things simple.
Actually, I had started the idea adding multi-valued API to GrlData, but 
everything become lot of complicated, so I tried to split up
single-valued and multi-valued API in two different classes, which
solved most of the problems.
Well, I fail to see where the complication comes from. Basically GrlDataMulti implementation should replace the old GrlData and the old APIs in GrlData that dealt with single valued properties should be adapted to deal with the first values for each key. Should be straight forward...
Yes, it introduces a new class, but I don't think it makes things more complicated. Actually, I think it helps to understand better the API, as 
user can focus on single or multi valued API just focusing in one or
another class.
We are introducing a concept that we wanted to make 100% transparent, so I disagree with this. I still don't see a good reason to do that and the fact that the implementation became more complicated doesn't sound very convincing to me, as I said, I fail to see what is complicated here.
The other thing I don't particularly like is the approach to correlated properties. The relations between the properties are not explicit (we do not have explicit data types mapping them), so when I get a GrlProperty 
 I might find thing a set of keys or another depending on the key I
requested and the relationships I established at run-time. I am not sure 
 if I like this better than having explicit types for each set of
correlated properties, although I admit this approach is more dynamic since the correlations can be established at run-time. Somehow it feels like we forced the solution to reuse code and I don't like that feeling.
I feel I'm not understanding the paragrapha, specially the "when I get a GrlProperty I might find thing a set of keys or another depending on the 
key I requested and the relationships I established at run-time".
I just mean that when you get a GrlProperty it is not obvious what other keys are there associated to the key you requested because there is no fixed data type exposing this, it is a GrlProperty for everything... In the API I put as an example you know very clearly that uri, mime, width and height, for example, are correlated for video items, you have a specific data type putting them together and specific APIs to handle this specific correlation, this makes everything more explicit. Plugin devs even have a specific constructor for this so they know they should put all these things together, etc
When creating relations between keys, there is a function to get those relations, so applications can get which keys are related, for instance 
with URI.
I know, what I am saying is that it is not explicit. We do not have specific data types and APIs for each correlation, we use the same data types and APIs for all of them, it is not that it is wrong, it is the fact that everything is less obvious. For me it is like the problem you have with scripting programming languages that are not strongly typed. You see generic APIs (like the generic GrlData API) acting over generic structures (like GrlProperty) and at times that is a problem for those trying to understand what is going on.
In the code example I dropped in my previous e-mail it is very clear at all times what is being done without having to look anywhere else. You see the data types, you see the correlations explicitly in the data types and you use specific APIs to handle them. It is more explicit.
Also, it provides APIs to ensure that plugin developers are aware of these correlations. When they create a GrlVideoUri object/structure they have a constructor asking for all the correlated elements, again in a explicit manner, etc.
But besides this, this relations defined by core are somewhat fixed, in 
the same way core register the predefined keys: we can add in
documentation which keys exists, and which keys are related with.
Let me clarify why I added this approach: plugins can define their own 
keys on run-time and this keys can correlated with other keys.
As example, Gravatar plugin introduces two new keys, "artist-avatar" and 
"author-avatar", and this keys are correlated with "artist" and
"author", respectively.

So I need to have a flexible way to handle this situation.
To be honest, I find the fixed correlations important (like having multiple uris and wanting to match ach of them with their mimes for exmple), but for other cases like the one you mention here I don't know if it is so important. My doubt is if this extra flexibility is worth it.
I guess the question here is if the extra flexibility we get from this approach and the code reuse is worth the additional slight obscurity.
The alternative to this, as I explained in an e-mail before would be to have explicit, fixed relations defined at compile time. Things like: 

 GrlDataVideoURI, GrlDataThumbnail, etc

 These would be structs:

 typedef struct {
   gchar *uri;
   gchar *mime;
   guint width;
   guint height;
   ...
 } GrlVideoURI;
And then we would have API to set and get these structs from a GrlData 
 object:

 GrlMediaVideo *video;
GrlVideoUri *uri_data = grl_video_uri_new (uri, mime, width, height); 
 grl_media_video_set_uri (video, uri_data);
 ...
 GrlVideoUri *uri_data = grl_media_video_get_uri (video);
 gchar *uri = grl_video_uri_get_uri (uri_data);
 gchar *mime = grl_video_uri_get_mime (uri_data);
 ...
As you can see, the correlations here are fixed, they are defined by structures, so they are explicit and we provide the users with specific APIs to handle each correlation,, which I think is less obscure than using a generic API. The drawback is of course that they are fixed, and that you have to create structures and specific API for each correlation 
 (more code) and you cannot define new relations at run-time.
Exactly. If Grilo wouldn't allow to create new keys by plugins, then of 
course I go with this approach.
But here there is an important point I would like to say: what I sent is a preliminary work that focus on the core part for adding multi-valued properties. Based on this work, we can add new api to ease some things, as we added api in GrlMediaAudio to ease its handle using GrlData api. 

Thus, maybe we can add your api proposal to GrlMediaVideo using
GrlDataMulti api to implement it.


And how would you do that exactly?

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