Re: Operation options (filtering, sorting and more)

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

On Fri, 2011-03-18 at 13:53 +0000, Iago Toral wrote:
> On Fri, 18 Mar 2011 13:32:29 +0100, "Juan A." Suárez Romero 
>  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)
> 

Ok. Just to make my point explicitly, though I think it is: I want the
latest API. And I don't mind having the first API too implemented over
the latest to simplify the client life, as we have done in other cases.

But, as you already pointed out, this is a personal preference.


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

It's true that your proposal is more clearer, but also less powerful. I
don't see a very big problem about doing:

filter_set(filter, GRL_METADATA_KEY_ARTIST, "Madonna");

and doing:

filter_set_artist (filter, "Madonna");

And as I said previously, and also in other emails, I'm up to add
specific API for common cases to simplify users life, like adding the
filter_set_artist() implemented over filter_set().

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

IMHO, while the API I'm proposing is more flexible, it is not the most
flexible thing in the world. You can't do OR operations, nor making
groups, nor filtering by something that is not a key.



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

Thanks to bring it. I totally thought you were talking about something a
bit more flexible.

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

Yeah, of course, and mine is my personal preference too.

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


Well, I hope this thread can be used for that.

It would be good if people can:

a) Bring here their opinion

b) Bring here examples of filters that they would need. Specially from
people that is using Grilo to implement their stuff.

	J.A.