Re: RFC: Operation Options API proposal

[Guillaume Emont <gemont igalia com>]

On 24/03/2011 12:45, Guillaume Emont wrote:
> (...)
> On 24/03/2011 10:33, Iago Toral wrote:
>> (...)
>> I think the proposal is good. I would start the implementation and then,
>> if we find issues we may need to adjust some bits.

So, well, I started throwing code at the problem, applying the now
famous methodology[1].

> Before starting, I think we need to ensure we agree on a few more points:
>  - inherit from GrlData? (I'd say yes)

After some more consideration, I took the problem from a safer angle,
and couldn't find many advantage of inheritance over composition in that
case. Whereas I can see some advantages in using composition (in a
private structure):
 - application/plugin developers will know what API to use with GrlCaps
(respectively GrlOperationOptions), and not hesitate with using the
GrlData API
 - for application/plugin developers that want some lower level stuff,
we can add a generic grl_caps_get/set_value(), with its documentation
stating that this is for people knowing what they are doing
 - the use of GrlData becomes an implementation detail

The only advantage I could find to inheritance is that it would allow a
slightly faster creation of objects, and a slightly lower memory
footprint. But then, if these issues are critical, I guess we should use
a plain GTYpe'd structure, and not a GObject.

So, how I'm starting the thing, is by having both GrlCaps and
GrlOperationOptions inherit from GObject, with each a GrlData in their
->priv.

>  - put all the stuff in GrlMetadataSource (and use grl_metadata_source_*
> methods on media sources as well)? (I'd say yes as well, and we need to
> plan quickly when to fix that class hierarchy)

Once I have what I want for GrlCaps/GrlOperationOptions, I will push it
on gitorious and send an email to the ml for some last checks before I
get into that part anyway, so that question is slightly less urgent.

Guij

[1] http://oppugn.us/posts/1300784321.html