Re: RFC: Operation Options API proposal

["Juan A." Suárez Romero <jasuarez igalia com>]

On Thu, 2011-03-24 at 13:36 +0100, Guillaume Emont wrote:
> I'm not sure I agree. Maybe the limit is a must, but not sure
> pagination
> per se is. If the underlying API doesn't support it (such as
> g_file_enumerate_children() in the case of filesystem), then the
> plugin
> writer has to bend backwards to implement a support for it that would
> be
> no better than a generic support in core. For the sake of maximising
> source simplicity, I think this should be a capability  from the point
> of view of the plugin (i.e. something optional), even though it would
> always look "available" for the application writer (core would modify
> the caps before passing them for that).
> 

The point is that if we make it optional, then i think we are
complicating developers' life, as they need to handle a new case:
sources don't supporting pagination at all.

Of course, as you mention, we could let sources to not implement
implementation, and just adding a way in core to do it. Actually, the
cancel() method works in that way: core provides a "default" cancel for
those sources that don't support it.

And from developer's pov, cancel is always a supported operation.

Should we do the same for pagination (that is, it is always a supported
operation, because there's a default implemention in plugin)? If so,
users will always notice that the capability is there.

In any case, I feel that making pagination a optional option is
something that needs a deep review.


	J.A.