Hi, One follow up task after F2F was to finish the implementation of the PagingIterable interface. This is finished now.
In the client impl module you'll find a unit test testing the default implementation. In FIT module all APIs returning an Iterable are also covered by basic unit tests. I have open points for discussion: a) Naming: Actually the interface behaves like an interval. Paging is more or less an optimization of the implementation not to read all elements in one call. My naming proposal would be "ItemIterable" for CmisObjects, QueryResults, Events, ObjectTypes ... b) Paging Parameter or itemsPerPage: Used in all API returning an Iteable e.g. PagingIterable<Document> getCheckedOutDocs(int itemsPerPage); As said this is more an optimization rather than a real page which should have a begin and an end. I propose to eliminate this parameter in API and assign it to the session (or OperationContext) as a global optimization parameter. c) SkipCount: Because of totalNumItems is an optional value (s. CMIS 2.2.1.1) an application can not necessarily calculate the maximum of skipCount parameter. Current implementation runs out of bound if skipCount > totalNumItems. This is maybe a bug and it would be better implementation accepts a high skipCount. In that case the Iterable returns not more items. d) skipTo(pos): I propose another (optional) parameter maxItems for this method. Currently the Iterable returns all elements. Let me know what do you think. Regards, Stephan
