Re: Adding filtering API

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

On Thu, 2011-01-20 at 08:46 +0000, Iago Toral wrote:
>  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).
> 

My concert is how plugins declare which kind of filtering are they
supporting. For instance, they should tell which fields they support for
filtering. But at the same time, they need to specify if they support
combinations or not.

If we found a way of doing it, then I agree providing a filtering
search, keeping the restrictions you mentioned (supporting only '='
operation, and the AND combination).

By the way, if finally we go with it, I have a proposal to do it,
something I thought some time ago, and that would make easier for
clients and plugins to handle the filtered search.

The idea is to provide a:

guint
grl_media_source_search_pattern(GrlMediaSource *source,
                                GrlMedia *pattern,
                                guint skip,
                                guint count,
                                GrlMetadataResolutionFlags flags,
                                GrlMediaSourceResultCb callback,
                                gpointer user_data);

as it can be seen, the signature is the same as in search(), but
replacing the "text" by "pattern".

What is pattern? It's a GrlMedia that client builds and fills with the
restrictions we wants. Plugin will provide all medias that matches with
that pattern.

For instance, if client wants all songs with artist 'Madonna' and album
'Ray of Light', she would create a pattern as:

GrlMedia *pattern = grl_media_audio_new();
grl_media_audio_set_artist (pattern, "Madonna");
grl_media_audio_set_album (pattern, "Ray of Light");

And invoke grl_media_source_search_pattern(). Plugin will return all
GrlMediaAudio where artist and album are the same as in the pattern.

The advantage is that for plugins it is more easier to parse properties
and values than using an expresion like "artist = 'Madonna' AND album =
'Ray of Light'"

	J.A.