Re: Operation options (filtering, sorting and more)

[Iago Toral <itoral igalia com>]

On Fri, 18 Mar 2011 13:32:29 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> On Fri, 2011-03-18 at 11:19 +0000, Iago Toral wrote:
> > >
> > > having it, I don't see why we need to restrict it to dates: we
> > could
> > > use
> > > it with other keys.
> >
> >  Because the point of this the API is not to be a generic filtering
> >  mechanism, but support a set of basic filters that we think make
> > sense
> >  for most sources, just as we would have, for example:
> >
> >  grl_filter_set_type_filter
> >
> >  we would have grl_filter_set_date_filter
>
> And why we want to have a filtering by date but not a filtering by
> bitrate, for instance?

As discussed previously, because I think filtering by date is a basic 
use case, while filtering by bitrate is not and we want to propose a 
simple and basic filtering API to deal with the cases that we consider 
basic, and nothing more.

> I know that in your proposal you mentioned the date range, but not 
> the
> bitrate or other key case.
>
> But I don't see why we need to restrict it if making it a bit more
> flexible doesn't add a big penalty to implement it, specially when
> sources are free to choose what keys they support in the range. If 
> they
> only support date, then good. But if they can support for other keys, 
> I
> think we should allow them to implement it.

Because following that reasoning we can very well end up with a generic 
filtering solution (or one that looks like it) that is not what I 
proposed nor what we agreed to do.

I want this kind of API:

filter_set_type
filter_set_date_limits
filter_set_album
filter_set_artist,...

I do not want this kind of API:

filter_set_ranged (key, min, max)
filter_set (key, value)

I want people to know from the API what exactly they can expect from it 
and do not get the idea that this is a generic filtering mechanism, 
because that is not what we want to do. The first API shows that very 
clearly, the second version looks like a generic filtering mechanism and 
if I see that I clearly do not know that it is not intended to be used 
like that, and the more we walk towards that kind of API, the worse in 
my opinion. This is also supported by the fact that I do not expect us 
to support tons of filters here, but just maybe 10-20 filters, the ones 
we consider basic and only those.

In summary, I want our filter API to be simple, clear and to the point. 
Flexibility is not my main concern here as far as it covers the filters 
I consider basic and can be easily extended to include more of these in 
the future if needed. If flexibility does matter, for that we have the 
query() interface, as always.

I would only like the approach to APIs receiving random keys as 
parameters if we have the idea of making the filtering API more generic 
in the future, but nobody has proposed that.

> If we want to add a specific filter for date, then the other filters
> should be specific for each key too. That is, having a:
>
> grl_filter_set_artist(...)
> grl_filter_set_album(...)
>
> And there is no filters for other keys.
>
> Is that what we actually want?

That is what I had in mind, yes.

> In the implementation I started I'm more flexible than that, allowing
> sources to specify which kind of keys they support on filtering. So 
> if
> they decide that can filter content by, let's say, license, then they
> are free to allow users to do it. And the same with the ranges
>
> Now, if you think that we must not be so flexible, then I'll change 
> it,
> but I'll deeply disagree :)

I think we should not be so flexible here, as I said we have the query 
API for more advanced stuff and that was always the point of it. I think 
we should try to address the problem we identified: there are certain 
filters that are very common and we should not force app devs to go and 
use query to make use of them.

And the "license" example you mention has nothing to do with this 
discussion.  If we do not consider the filter interesting enough to be 
included now (no matter the reasons), does it mean plugin developers 
cannot offer that functionality? No, they can implement query() and 
offer that filter through that interface, so it is not like we are 
preventing them from providing the feature. But what if we then realize 
the filter is so nice that many sources will be providing that feature 
and many apps want to use it? Well, then we can add 
grl_filter_set_license and problem solved.

This is what I really think and what I would like to see, but hey, this 
is not black or white and what I say here only represents a personal 
preference. In this scenario I value simplicity and clarity over 
flexibility, and in your case you prefer extra flexibility instead, both 
options are valid, it is a matter of preference, and I don't think your 
proposal is wrong.

I suggest that you discuss this Guillaume and others who might be 
interested in this topic and if you see people are aligned with your 
proposal, then go for it.

Iago