Re: RFC: Operation Options API proposal

["Juan A." Suárez Romero <jasuarez igalia com>]

On Tue, 2011-03-29 at 13:35 +0200, Iago Toral Quiroga wrote:
> 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.
> 

Uhm... I think I'm not getting what do you mean by "multi-valued
options".

Do you mean setting for instance a filter with with ARTIST and ALBUM in
just one call?


> 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.
> 

Well, that is why I showed the doubts.

The generic GrlOptions is used to store pairs of <key, value>. To be
honest, I'm not sure if this is too simple for our requirements.

As I said in other emails, for me GrlOptions should have a place to
store options related sorting, another place to store filters by type,
another place to store filters by key_equal, and so on.

In my preliminary implementation, that is how I did: I have a place to
store the filters by type, and another place to store the filters by
key.

But of course, maybe this is my limitation in fully understanding the
GrlOptions, and maybe Guillaume knows how we should deal with this.

> 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);
>     ...
> }
> 

In the preliminary implementation I did that would fit in this way:

keys = grl_filter_get_equal_keys (filter);
while (keys) {
   grl_filter_get_equal_key (filter, keys->data, &value);
   ...
   keys = g_list_next (keys);
}

keys = grl_filter_get_ranged_keys (filter);
while (keys) {
   grl_filter_get_ranged_key (filter, keys->data, &lower, &upper);
   ...
   keys = g_list_next (keys)
}

> 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);
>     ...
> }
> 


Yes, I provide also more generic functions, like

grl_filter_get_equal (filter,
                      GRL_METADATA_KEY_ARTIST, &artistvalue,
                      GRL_METADATA_KEY_ALBUM, &albumvalue,
                      NULL);

grl_filter_get_ranged (filter,
                       GRL_METADATA_KEY_ARTIST, &lower, &upper,
                       NULL);


	J.A.