Re: Operation options (filtering, sorting and more)

[Guillaume Emont <gemont igalia com>]

On 18/03/2011 12:10, Iago Toral wrote:
> 
> 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?

I like the idea, though it makes the whole "operation options" task much
bigger.
How about we start with capabilities supporting only the filtering and
sorting capabilities? That way, we can get out these features quickly,
and afterwards extend the capabilities to all that is logically a
capability in a source.


Guij