Re: RFC: Operation Options API proposal

[Iago Toral Quiroga <itoral igalia com>]

El mar, 29-03-2011 a las 12:18 +0200, Guillaume Emont escribió:
> On 29/03/2011 11:37, Juan A. Suárez Romero wrote:
> 
> > 
> > But, honestly again, I do not see exactly how this would fit on
> > Guillaume's proposal. Seems for me that the operations is more or less a
> > list of (option, value) pairs.
> Yup, that's the idea, trying to keep it simple. Then value can be of a
> complicated type if you need, and you can have APIs to facilitate for
> sets of options that go together (even if internally they are
> represented by more than one (option, value) entry).

I have a feeling that we may need to extend/change the API to have
explicit support for multi-valued options. Having a single "filter"
option with various values (each an independent filter) looks like a
cleaner way to go about filters to me and I guess the idea of
multivalued options in general makes sense.

If we go with the more generic approach to filters, then I guess the
"value" part of grl_add_option should be some complex data type, some
GrlFilter instance or something like that. And we would have it
subclassed for things like ranged filters, equal_filters, etc not sure,
but this is something you guys have to figure out to test if this whole
API makes sense :)

With the less generic approach, the client API side of things is clear:
they do not have to see any GrlFilter things or anything because they
have specific APIs tailored for specific supported filters, but we still
need to figure how these APIs store the data of the filters in the
GrlOptions objects at least.

Also, in both cases we also need to figure out how the
GrlOptions/GrlCaps objects would store the info about the various
different filter types and how plugin developers would get access to
them and identify them properly: that is, when in a plugin code I get
the value of the "filter" option and I get something (a pointer?), how
do I figure what kind of filter that is and how I should use it.

My original idea, in the case of the less generic approach, would be
that we would have specific APIs again:

filter = grl_options_get_filter (options, 0);
type = grl_filter_get_type (filter);
switch (type) {
  GRL_FILTER_DATE:
    grl_date_filter_get_limits (filter, &lower, &upper);
    ...
  GRL_FILTER_ARTIST:
    grl_artist_filter_get_artist (filter, &artist);
    ...
}

We could maybe have a more generic APIs to consume the filters (probably
using GValue in that case):

filter = grl_options_get_filter (options, 0);
type = grl_filter_get_type (filter);
switch (type) {
  GRL_FILTER_DATE:
    grl_filter_get_args (filter, 0, &lower, 1, &upper, -1);
    ...
  GRL_FILTER_ARTIST:
    grl_filter_get_args (filter, 0, &artist, -1);
    ...
}

We need to have these things clear before we can consider the
GrlOptions/GrlCaps API ready to go.

Iago