Re: Operation options (filtering, sorting and more)




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


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