Adding filtering API

[Iago Toral <itoral igalia com>]

Hi,

I think it is interesting to continue this discussion in its own 
thread.

On Tue, 18 Jan 2011 14:25:55 +0200, Jussi Kukkonen 
<jku linux intel com> wrote:
(...)
> We discussed extending the Search interface yesterday in IRC, I'll
> document my thoughts on that here as it's quite related: the search
> function could be extended, or additional slightly more complex
> search-functions could be added. I think the media-type-filter is an
> obvious addition (and one we would definitely use), but it's possible
> that other users would like more options so it might pay off to make
> this easily extensible...
>
> The search options I could see myself using in other situations are
>   * text (find string(s) in title, artist, etc.)
>   * artist (find string in only artist, creator, etc fields)
>   * title (find string in media title)
>   * type (match media type)
>   * (possibly some date-filtering)
> I'd expect that all given options should match in a returned result.

For the record, I just checked what kind of filters youtube permits:
http://code.google.com/intl/es-ES/apis/gdata/docs/2.0/reference.html#Queries

- Author / Uploader
- Date
- Category
- Geo Location
- Duration (short, medium,... not actual numbers) --> this is not 
documented AFAICS

Too restricted, even for cases one would consider obvious like finding 
strings on specific fields (Youtube would just search on all of them, 
and that's it).

My feelings is that we should add a *very basic filter API* to 
search(), or maybe create a filtered_search() API. Probably the latter 
would be a better option.  This API would restrict what you can filter 
to the very basic things that one would expect could be available in 
most services, and I would make it so the actual filters are very 
simple.

Some thoughts on what I mean by simple filters:

I think in *most cases*, only one filter is needed (that is, you filter 
by date *or* you filter by album, but not by both), but if more than one 
filter is needed, *usually* they would all be joined by AND operators 
(example: songs from this artist AND this album). This could be used for 
example for defining tailored browsing structures where a particular 
category may impose filters with various AND operations. In some cases 
OR operators could be used, although I think use cases for this are less 
obvious (example: songs of this artist OR this other artist). Cases 
where you have AND and OR operators in the same filter do not seem very 
likely to me for traditional apps (example: songs of this artist OR 
songs of this other artist AND date-min=whatever), specially because the 
more complicated the filter is the less likely it would be supported by 
all the plugins.

Are these assumptions reasonable?

If they are, I would go with a filtering support with the following 
limits:
- Limited filters, filters on random metadata would not be allowed like 
(bitrate = X). Still it should be easy to extend the list of allowed 
filters.
- No support for grouping operations like this: (artist=X AND album=Y) 
OR (date-min=Z AND artist=A).
- No support for operator precedence (plugin developers would not 
ensure certain precedence for operators), or we could just force all the 
operators of one filter to be of the same kind.
- No support for operators other than "=", so no filters like (artist > 
X) or (album != Y)

Of course, we could be more flexible than this if we think is worth the 
effort, so I would like to hear your thoughts on this matter. For 
example, we can have plugins declare what keys the support for filtering 
and remove the limited filters restriction (Grilo could check the 
filters provided by the users and simply remove the parts that are not 
supported or fail the operation if unsupported keys are used in the 
filter before passing the filter to the plugin).

The whole point is: let's have some basic filtering support that 
enables 80-90% of what users would expect, and clients use query for the 
remaining 10-20%.

Iago