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]
On Jan 16, 2013, at 7:48 PM, Summers Pittman <supittma@redhat.com> 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@gmail.com> 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@redhat.com>
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



    

    

  


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev