Re: Operation options (filtering, sorting and more)

On Fri, 18 Mar 2011 13:56:19 +0100, Guillaume Emont <gemont igalia com> wrote:
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
> 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?


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

/* 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

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
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.

The con is that we will have to change the API twice instead of just once, but I guess it is not a big problem at this point in the project. At any rate, I think we should address the rest of the options immediately after dealing with the filters and sorting features.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]