Re: Operation options (filtering, sorting and more)

[Iago Toral <itoral igalia com>]

On Tue, 15 Mar 2011 17:19:06 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> On Tue, 2011-03-15 at 16:43 +0100, Iago Toral Quiroga wrote:
> > > Juan's branch have them merged, but I feel this makes some 
> > structure
> > > members, and some APIs have names that aren't as simple and 
> > obvious
> > as
> > > they could.
> >
> > Since I have not looked at the code this explanation is a bit too
> > abstract for me to align with one option or the other, can you or 
> > juan
> > drop a couple of significant examples here?
>
> Sure.
>
> Firstly note that I will only refer to filtering, and I was focusing 
> on
> this work.
>
> The GrlFilter API is divided in two kinds:
(...)
> Some of the functions are used by clients, while other functions are
> used by plugins, to check what users want.

Ok, thanks for sharing. After seeing the API you are working with I 
agree with Guillaume that it is not as obvious as it should be and 
thinking about it a bit more I am more for having two types, one to 
represent the "list of options supported by a source", which is 
something declarative/static, produced by sources and consumed by 
clients, and one to represent "the actual options we want to use for a 
given operation", which is dynamic, not declarative, produced by clients 
to be consumed by sources.

But I also think the idea of having two types should be extended to 
cover other things. Right now we have supported_keys() for example, or 
slow_keys(), etc. These are more declarative interfaces which purpose id 
to let the user know what the source is capable of. I think we should 
define a type to define these capabilities or options and provide API 
along with it.

Off the top of my head, and to illustrate this with something less 
abstract:

/* client code */
GrlMetadataSource *source = grl_plugin_registry_get...()
GrlCaps *caps = grl_metadata_source_get_caps (source);
GList *supported_keys = grl_caps_get_supported_keys (caps);
GList *slow_keys = grl_caps_get_slow_keys (caps);
GList *supported_filters = grl_caps_get_supported_filters (caps);
...
/* More examples of client code and GrlCaps API */
if (grl_caps_supports_type_filter (caps) {
}
if (grl_caps_supports_sorting_direction (caps) {
}

I guess you get the idea: put all (most of) the things that define what 
a source is capable of behind a single object/API with an entity of its 
own.

Then, I think we should make the sources declare their caps in a way 
consistent with the API/object the clients are using. Basically it would 
mean that we should merge things like these supported_keys, slow_keys, 
and maybe other vmethods in GrlMetadataSource into a single function to 
be implemented by sources that returns a caps object.

What do you think?

Iago