Re: [aerogear-dev] Client Paging Strawman

-"send again corrected with the link to android spec"- Hi, continue on with what Summers said about the "scrollingMetaDataLocation" in iOS[1] I have a question. I believe these are the parameters that can override the behaviour for paging (taken by the JS gist here [2]): a) "scrollingMetaDataLocation(iOS) or paged(js) // "headers" or "content" to describe where to find the paging metadata, b) "offset": {String} // override the name of the "offset" param either in the header or in the content, default is "AG-Paging-Offset" for header and "paging.offset" for content c) "limit": {String} // override the name of the "limit" param either in the header or in the content, default is "AG-Paging-Limit" for header and "paging.limit" for content d)"total":{String} // override the name of the "total" param either in the header or in the content, default is "AG-Paging-Total" for header and "paging.total" for content e)"next":{String} // override the name for the "next" link either in the header or in the content. Default is undefined

f) "prev":{String} // override the name for the "prev" link either in the header or in the content. Default is undefined So, as Summers said, I believe all these params must be set upfront, instead of passing the possible overridable params when we create a readWithFilter. That is, it is fine when we do the first "readWithFilter", but it will become cumbersome when afterwards need to change the limit offset param and we need to pass along again these params. So my question, where should we add these config parameters? In a separate object (e.g. PageConfig) that will hold these params and then be set on the PipesConfig object during the creation of the pipe? I believe that is what JS does now. On android[3] I see that these parameters were added in the existing PipesConfig object Any thoughts? Thanks, Christos [1] https://gist.github.com/cbff741b3b21a50c3b67 [2] https://gist.github.com/4531575 [3] https://github.com/aerogear/aerogear.org/blob/6c811413be17976913eaaa3498e... On Jan 16, 2013, at 7:48 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: On 01/16/2013 12:44 PM, Matthias Wessendorf wrote: I tweaked the iOS API a bit more: https://gist.github.com/cbff741b3b21a50c3b67 Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level thing (like encoding or authentication) instead of a request level thing? I don't imagine it changing during the lifetime of a Pipe? Otherwise looks really good! I also updated the "comparison" gist: https://gist.github.com/4546737 Feedback welcome.... On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: the timeout parameter would be a general property of read() and not related to Paging ? On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: On 01/16/2013 10:23 AM, Bruno Oliveira wrote: Good point Summers. Might be an obvious question, but there we go. Are we planning to include timeout as parameter? For example: I want to retrieve a list of a bazilion users, and I want to specify the timeout acceptable to wait. I didn't get the chance to look at each API, just double checking here. +1 I was thinking about this yesterday. I want to but was hoping we could get the "shape" of the API nailed down first before we started hammering on specifics. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev