Re: [aerogear-dev] Client side Paging Spec

On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> My suggestion is to name these two parameters something more generic like locator/count where locator=page/offset and count=limit/perPage. Then in our configs we would provide these options: >> >> pagingType {String} - determines the paging method to be used in calculating next page, etc. and could be either "offset" or "page", default "offset" >> locatorParam {String} - locator parameter name, default "offset" >> locatorValue {Number} - page index or offset >> locatorIdentifier {String} - the locator identifier name, default "AG-Paging-Offset" >> countParam {String} - count parameter name, default "limit" >> countValue {Number} - items per page >> countIdentifier {String} - the count identifier name, default "AG-Paging-Limit" >> >> Thoughts? OK.... I agree that you raised a valid concern, regarding that the client needs to indicate whether paging information is sent as headers, as query parameters, or as body data. But I still am not so sure if the above args are all really needed, a ton of cfg params make it a bit fishy. How about, using the following as a default "parameter provider" - offset (which sets the offset of the first element that should be included in the returned collection) - limit (the number of results that should be listed on a page) OK. Now if a user wants/needs to provide a different parameter schema (imagine his/her lame server requires/supports "page", "perPage" and "sorting"): The developer could just create a custom impl (iOS: block, Java: anonymus class impl of an interface, JS: callback function) and pass it to the "paging request". that way the dev. could even add a ton of more params (if the lame backend requires that). since the pipe (or the paging request) knows whether the paging information is sent as headers, as query parameters, or as body data, it would just "serialize" the give "param provider" into the actual location. Any thoughts?