Re: Operation options (filtering, sorting and more)

[Iago Toral <itoral igalia com>]

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

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.

Iago