Re: [PATCH 00/15] Plugins: caps and options

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Fri, 2011-12-02 at 18:41 +0100, gemont igalia com wrote:
> These patches provide the modifications needed to adapt the plugins to
> the new
> caps and options APIs[1]. 

I didn't find any specific issue, besides the ones I've commented in
previous emails.


But after reading this patchset, an idea came up in my mind regarding
the new capabilities features, and the old auto-split mechanism we have
in core. It is not a real proposal, but just a way of writing down an
idea in some place :)

Refreshing the memory, there are some plugins that have a physical
limitation on how much elements can return in a row. The auto-split
mechanism is a way of hiding this issue for client. That is, if a plugin
is only to deal with 100 elements in a row, and the user asks for 250,
the auto-split chunks that request before asking the plugin.

This auto-split is a feature that is actually a commodity for user, to
avoid them doing the split, but that adds complexity to the core. Since
lot time ago I was feeling that this auto-split should be an utility
provided to the user as we provide GrlNet, for instance. But I never
knew how to move it out of core.

Now that capabilities has been included, it seems easier for me. A
plugin should declare in his capabilities that he can deal with, let's
say, 100 elements as much. Without autosplit, the user would read this
limitation and would adjust his 'count' value to that limitation. Of
course, I think that auto-split is still a good help, so I would add it
as an utility; that is, if user don't want to deal with this limitation,
we would use that utility to ask without limit, and the utility would do
the chunks accordingly. This would remove complexity from core, and make
it easier to maintain.

Of course, I'm not saying that we should do it right now; auto-split
works fine, and probably there is no need to change it. But if in future
we need to do more refactors, and the auto-split is just another
complexity to deal with in the core, we could consider it.

	J.A.