Grilo advanced filtering

[Jens Georg <mail jensge org>]

As we discussed before, the current filtering is a "narrowing down" or a
logical "AND" of a selected set of filters. 
How open would you be to a more broad solution of the filtering issue,
thinking of the tracker or similar future plug-ins?

I've several proposals to make that work, all would imply some caps to
indicate whether the desired back-end really supports this or not:

a) Simple: Instead of passing just one GrlOperationOptions, pass a list
of options. Filters inside the options would be still "AND", the list
would be considered a large "OR". 
That of course implies that the result slicing is moved out of
GrlOperationOption, or, as a "quick hack/contract", is only obeyed in
the first list entry. 
It has the benefit that it would be using existing stuff, not delay 0.2
too much and if I'm not completely mistaken quite powerful already.
  
b) More complex: Dissolve GrlOperationOptions, have several filter
objects and logical operations that can be combined freely, much like
QtGallery's filtering.
Has the benefit that it's more flexible in terms of what filters you can
glue together, you don't have to check if something in the
OperationOptions is really set, but might be awkward to construct
filters from C, that's where

c) Filter Language: comes into the field. Have a simple language that is
easily transformable in other languages such as SQL, SPARQL etc. as a
substitute for filtering and the generic query language you already
provide. This sounds slightly more complex, but in fact could be build
upon both a) and b), with b) being easier, a) requiring some boolean
normalization in the process, then transforming to target filter
language.

Thoughts, opinions, other ideas?