Re: Filtering by type

[Iago Toral <itoral igalia com>]

On Mon, 24 Jan 2011 13:32:37 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> Hello.
>
> Some days ago, Iago sent a proposal to have a "filtered" search(), 
> that
> would search data that matches a criteria. Thus, we can search by
> artist, album, ..., or combinations of them.
>
> The proposal here is not a replacement, but a complement of Iago
> proposal. Both would live together.
>
> First of all, let me show you an user case. Lets think I'm 
> implementing
> a ImageViewer using Grilo. Of course, I'm only interested in
> GrlMediaImage content. So when using browse()/search()/whatever
> function, I must filter the content to just get what I'm interested 
> in.
>
> It would be good to have a way of telling Grilo that I'm only 
> interested
> in specific content. Doing the filtering myself means that plugins 
> are
> doing unneeded work.
>
> Notice that Iago's proposal just focus in the search() operation, 
> while
> here we are interested in other operations, like browse().
>
> So the proposal here is to use the GrlMetadatadataResolutionFlags to 
> add
> flags about which kind of content the client is interested.
>
> Thus, in the user case exposed above, we can have a GRL_RESOLVE_IMAGE 
> to
> just get GrlMediaImages and forget about other results[1].
>
> If we are implementing a audio-video multimedia player, we can user
> GRL_RESOLVE_VIDEO | GRL_RESOLVE_AUDIO to get only audios and videos, 
> and
> forgetting about photos[1].
>
> From plugins pov, they can check if user is asking for content that 
> they
> can provide; for instance, Jamendo will check if GRL_RESOLVE_AUDIO is 
> in
> the flags; if not, then it will invoke the callback() with no 
> results;
> else it will perform as usually.
>
> This proposal has the advantage that it doesn't needs a change in the
> api: we can use the same api.
>
> I think that I already discussed this proposal with Iago, and he 
> agreed
> that we can do it as a first approach.
>
> As usual, comments are welcomed.

Actually, the reason I sent the other proposal is because in the end, 
this you are proposing is no more than a patch to a bigger problem.

Filtering by using the flags is a possibility indeed, but by no means 
looks like the proper way to do such thing. Filtering by date is 
something that probably makes sense too, something we might end in the 
future even if for now we could live only with the content-type filter, 
so for me if we want to do something about this we need to define a 
filtering API, trying to be conservative with its scope and increase it 
as things are needed, but we need the filtering API.

The flags were not intended to be used like filters. They can be used 
only for certain kind of filters (you would not be able to use them to 
filter by date for example), but that's not their purpose. If we need 
filtering let's do it right and add filtering API, even if we want to 
make it simple. Let's not mix things that are not the same.

Also, there is no point in having both a filtering API (which you can 
use to filter by content type and other things) and then the flags 
(which would also allow you to filter by content-type). Makes no sense 
IMO. Let's use the filter API for filtering and let's use the flags for 
what they were intended to be used for.

So summing up, my opinion is that we should discard the idea of 
filtering using flags and focus only on adding the filter API. Sorry 
that I did not mention this explicitly in the email were I proposed to 
add a filtering API, I thought it would be obvious that it was intended 
to be a complement of this option.

Iago