Re: RFC: Operation Options API proposal

On Fri, 2011-03-25 at 12:47 +0100, Iago Toral Quiroga wrote:
> > Also, maybe Juan can tell us whether the above model fits his ideas
> for
> > filtering.
> Yes, please :)

Apologies for not answering before.

Well, this caps/options model stuff regarding filtering by key (I think
filtering by type is more or less solved with the proposal) depends
quite a lot on the discussion about what we want to allow in

The proposal discussed were two:

1) Having a fixed set of keys that user/plugins use to filter the
content. Some of this keys will check for equality[2] (artist, album)
and others will check for range[3] (specifically, only 'date' was

2) Have a more dynamical list of supported keys for filtering: plugins
states which keys they support for filtering by equality and which keys
they support for range.

Regarding proposal (1), as the filters are fixed, we would have a list
of functions similar to filter_type():

grl_operation_options_set_filter_artist (options, "artist-value");
grl_operation_options_set_filter_album (options, "album-value");
grl_operation_options_set_filter_date (options, "min-date", "max-date");

Each time the "set_filter_foo()" is invoked, the filter is appended to
list of previous filters, so at the end plugin will return values that
matches all filters.

Regarding proposal (2), this is the one I chose to implement filtering
by key. I have first version working with UPnP plugin[4] (which of
course does not use the GrlOperation proposed here).

In this version, the plugin declares which keys it supports for
filtering by "=" operator, and which keys it supports for "range"

To be honest, I'm not very very sure about how it would fit the
proposal. One possibility that comes to my mind would be having
something like:

grl_operation_options_set_filter_equal (options,
grl_operation_options_set_filter_equal (options,
grl_operation_options_set_filter_range (options,

As I explained in previous emails, we can add on top of this a set of
functions to easing the life of plugins if we see it's worth to (that
is, basically adding the functions in proposal (1) on top of proposal

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.


[2] By equality I mean keys that allow to do "<key> = <value>"
[3] By range I mean keys that allow to do "<minvalue> <= key <=
[4] and

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