Hi, based on today's IRC and mailing list discussions, I have polished the client side paging spec: https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... Please review the document! Cheers! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: > Hi, > > based on today's IRC and mailing list discussions, I have polished the > client side paging spec: > > https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... > > Please review the document! > > Cheers! > Matthias > +1, let's see how it works in actual implementation! _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Just realized, offsetValue propbably should be a limit. For instance reddit pages based on a hash looking thing (ex http://www.reddit.com/?count=25&after=t3_16r4z0)

On Thu, Jan 17, 2013 at 03:09:32PM -0500, Summers Pittman wrote: > Just realized, offsetValue propbably should be a limit. For > instance reddit pages based on a hash looking thing (ex > http://www.reddit.com/?count=25&after=t3_16r4z0) this after is a genuine offset fwiw :P

-- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jan 17, 2013, at 2:55 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Thu, Jan 17, 2013 at 8:00 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> I'm pulling the conversation from IRC to this thread as I'm not sure if I'm explaining my issue with offset/limit properly. > > a quick summary ? The summary followed on the next lines. :) > >> >> Basically, my concern is we can not choose one between offset/limit and page/perPage. The client libraries need to support both as both are popular server-side paging implementations. >> We also can't just use one of those names and have it work both ways since that would be confusing to developers. > > Not sure I understand, perhaps due to lack of thread/understanding, but > > We can override the actual name of the http request parameter. so if I > am doing this: > offsetParam="page" > offset=1 > limitParam="perPage" > limit=5 > > this would translate into ?page=1&perPage=5 - right? But this is what I find confusing. Calling something an offset and meaning page or vice versa, has already tripped us up. Just think of what it will do to users trying to understand our API. That is why I suggested a name change and the ability to specify what type of paging is happening.

> > And the server (github in this case) I am going against would return > me some "collection". That's all the client need to understand. > > >> >> 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? > > > hrm, not sure if this makes the API a bit complicated. Or at least I > don't (now) see the benefit of that. > > -M > >> >> On Jan 17, 2013, at 12:23 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >>>> Hi, >>>> >>>> based on today's IRC and mailing list discussions, I have polished the >>>> client side paging spec: >>>> >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>> >>>> Please review the document! >>>> >>>> Cheers! >>>> Matthias >>>> >>> +1, let's see how it works in actual implementation! >>> _______________________________________________ >>> 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

Kborchers and I were on chat and have the following things to comment on/finalize 1)Add some options to PipeConfig to indicate whether paging information is sent as headers, as query parameters, or as body data

and 2) the result from Pipe.read will include the next and previous methods. Previously we had been discussing have read take a parameter "next","prev" etc.

2.a) Paging state (offsetValue, limitValue) will be passed to read and not be properties of the pipe.

On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: > Hi, > > based on today's IRC and mailing list discussions, I have polished the > client side paging spec: > > https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... > > Please review the document! > > Cheers! > Matthias > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jan 17, 2013 at 11:36 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > Kborchers and I were on chat and have the following things to comment > on/finalize > > 1)Add some options to PipeConfig to indicate whether paging information > is sent as headers, as query parameters, or as body data I can see this is handy. Right now it would be always query parameters. I will update the spec to reflect this. > and > > 2) the result from Pipe.read will include the next and previous > methods. Previously we had been discussing have read take a parameter > "next","prev" etc. Not really... The JS version of the read was doing this: read(page:"next", ......) the Java/iOS bits were already returning some "paged list", on which you can invoke next/prev. How has this changed? Please explain

> 2.a) Paging state (offsetValue, limitValue) will be passed to read and > not be properties of the pipe. Again, not seeing a huge change here, since Java/iOS already take a "read filter", which has the offset, limit etc "configuration"

Regarding 2a, I don't even need to update the spec, since it is abstract enough to say the "paging" needs some configuration. Fortunately it does NOT say, how to apply them... so that's up the the actual impl. -Matthias > > On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >> Hi, >> >> based on today's IRC and mailing list discussions, I have polished the >> client side paging spec: >> >> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >> >> Please review the document! >> >> Cheers! >> Matthias >> > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev

Kborchers and I were on chat and have the following things to comment on/finalize 1)Add some options to PipeConfig to indicate whether paging information is sent as headers, as query parameters, or as body data

and 2) the result from Pipe.read will include the next and previous methods. Previously we had been discussing have read take a parameter "next","prev" etc. 2.a) Paging state (offsetValue, limitValue) will be passed to read and not be properties of the pipe. On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: > Hi, > > based on today's IRC and mailing list discussions, I have polished the > client side paging spec: > > https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... > > Please review the document! > > Cheers! > Matthias > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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? -M > > > Any news on this ? > > -Matthias > >> >> On Jan 17, 2013, at 12:23 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >>>> Hi, >>>> >>>> based on today's IRC and mailing list discussions, I have polished the >>>> client side paging spec: >>>> >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>> >>>> Please review the document! >>>> >>>> Cheers! >>>> Matthias >>>> >>> +1, let's see how it works in actual implementation! >>> _______________________________________________ >>> 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

But if we go for this solution, we must also add in the usage page a section showing a custom impl to pass the parameter.

On Fri, Jan 18, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > +1 with Matthias's suggestion. > > > On Fri, Jan 18, 2013 at 9:25 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: >> >> 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? >> >> -M >> >> >> >> >> >> >> > >> > >> > Any news on this ? >> > >> > -Matthias >> > >> >> >> >> On Jan 17, 2013, at 12:23 PM, Summers Pittman <supittma(a)redhat.com&gt; >> >> wrote: >> >> >> >>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >> >>>> Hi, >> >>>> >> >>>> based on today's IRC and mailing list discussions, I have polished >> >>>> the >> >>>> client side paging spec: >> >>>> >> >>>> >> >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >> >>>> >> >>>> Please review the document! >> >>>> >> >>>> Cheers! >> >>>> Matthias >> >>>> >> >>> +1, let's see how it works in actual implementation! >> >>> _______________________________________________ >> >>> 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 >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> 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

this is "paging config" (e.g. a JAva-ish read filter) - or "pipe config" (a pipe config object) ?

On Fri, Jan 18, 2013 at 07:00:21AM +0100, Matthias Wessendorf wrote: > this is "paging config" (e.g. a JAva-ish read filter) - or "pipe > config" (a pipe config object) ? I suppose is a pipe config, given that having different paging rules for the same endpoint would be really contrived as they could be :P -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

solved... updating the spec On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> 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. > > This is the part I don't understand so sorry if I'm the only one being dense here. I believe that is basically what we decided to do yesterday, but, without that initial config, how do I make the initial request for the first page? Since the callback that the dev would provide isn't triggered until a successful read so that it can "build" the next/prev methods based on the response, how do I make that first request? > >> >> Any thoughts? >> >> -M >> >> >> >> >> >> >>> >>> >>> Any news on this ? >>> >>> -Matthias >>> >>>> >>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>> >>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >>>>>> Hi, >>>>>> >>>>>> based on today's IRC and mailing list discussions, I have polished the >>>>>> client side paging spec: >>>>>> >>>>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>>>> >>>>>> Please review the document! >>>>>> >>>>>> Cheers! >>>>>> Matthias >>>>>> >>>>> +1, let's see how it works in actual implementation! >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

+1 to 1) and 2) under the Pipe creation but also 3) , because if one has a custom impl for a pipe , he probably needs it for each read Okay for PipeConfig.updateParameterProvider() but he should also be able to pass anytime through the read() to reconfigure , no ? doesn't hurt to have many options to reconfigure IMO Just a last remark on the "locations" name : metadataLocation and pagingLocation are not enough clear to me to see what's coming in and out, as suggested on IRC : metadataLocationResponse and metadataLocationRequest ? On Fri, Jan 18, 2013 at 3:38 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > Looking at [1] > > > There is ONE detail left... > > The paging "config" contains the following settings: > 1) locations: > - metadataLocation > - pagingLocation > 2) param provider: > - my custom impl (like in https://gist.github.com/4564403#comment-732025 > ) > OR > - default (limit + offset) > 3) web linking: > - nextIdentifier > - previousIdentifier > > > Now... where to put these options? On the pipe, or on the actual > "paging read" (e.g. readWithFilter....). > > I can see that 1) and 3) are nice on the umbrella Pipe > definiton/creation. I can also see that it's OK to "install" a "param > provider" on the pipe as well... > > If the "params" changes (for whatever reason), there could be a > "PipeConfig.updateParameterProvider()" hook.... > > I also think..... the parameter provider can be defined on the actual > read (get request).... > > thoughts? > > -M > > [1] > https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... > > > > > On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > solved... updating the spec > > > > On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> > >> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > >> > >>> 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. > >> > >> This is the part I don't understand so sorry if I'm the only one being > dense here. I believe that is basically what we decided to do yesterday, > but, without that initial config, how do I make the initial request for the > first page? Since the callback that the dev would provide isn't triggered > until a successful read so that it can "build" the next/prev methods based > on the response, how do I make that first request? > >> > >>> > >>> Any thoughts? > >>> > >>> -M > >>> > >>> > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> Any news on this ? > >>>> > >>>> -Matthias > >>>> > >>>>> > >>>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman <supittma(a)redhat.com&gt; > wrote: > >>>>> > >>>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> based on today's IRC and mailing list discussions, I have > polished the > >>>>>>> client side paging spec: > >>>>>>> > >>>>>>> > https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... > >>>>>>> > >>>>>>> Please review the document! > >>>>>>> > >>>>>>> Cheers! > >>>>>>> Matthias > >>>>>>> > >>>>>> +1, let's see how it works in actual implementation! > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> > >>>> > >>>> > >>>> -- > >>>> Matthias Wessendorf > >>>> > >>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>> sessions: http://www.slideshare.net/mwessendorf > >>>> twitter: http://twitter.com/mwessendorf > >>> > >>> > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> _______________________________________________ > >>> 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 > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > +1 to 1) and 2) under the Pipe creation but also 3) , because if one has a > custom impl for a pipe , he probably needs it for each read Actually.... since NEXT does change the offset (from https://gist.github.com/4537431): My current "page" is "https://localhost/demo/cars?offset=20&limit=10" This means I get something like for next/prev: <https://localhost/demo/cars?offset=10&limit=10>; rel="previous", <https://localhost/demo/cars?offset=30&limit=10>; rel="next", So... for iOS... the [next]; (or previous) would INTERNALLY do this: [_pipe readWithFilter:^(id<AGFilterConfig> config) { [config setLimit:_limit]; [config setOffset:_offset]; // got increased before } success:success failure:failure]; So... I think this is already impl detail, but when there ARE no meta-information for NEXT/PREV available, the user has to maintain that himself.... so passing the (updated) parameter provider on the read is nice.... Christos and I tend to do that for iOS. I guess Summers will be on the same page (haha) with his Android code -M > > Okay for PipeConfig.updateParameterProvider() but he should also be able to > pass anytime through the read() to reconfigure , no ? doesn't hurt to have > many options to reconfigure IMO > > Just a last remark on the "locations" name : metadataLocation and > pagingLocation are not enough clear to me to see what's coming in and out, > as suggested on IRC : metadataLocationResponse and metadataLocationRequest ? > > > > > On Fri, Jan 18, 2013 at 3:38 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: >> >> Looking at [1] >> >> >> There is ONE detail left... >> >> The paging "config" contains the following settings: >> 1) locations: >> - metadataLocation >> - pagingLocation >> 2) param provider: >> - my custom impl (like in https://gist.github.com/4564403#comment-732025) >> OR >> - default (limit + offset) >> 3) web linking: >> - nextIdentifier >> - previousIdentifier >> >> >> Now... where to put these options? On the pipe, or on the actual >> "paging read" (e.g. readWithFilter....). >> >> I can see that 1) and 3) are nice on the umbrella Pipe >> definiton/creation. I can also see that it's OK to "install" a "param >> provider" on the pipe as well... >> >> If the "params" changes (for whatever reason), there could be a >> "PipeConfig.updateParameterProvider()" hook.... >> >> I also think..... the parameter provider can be defined on the actual >> read (get request).... >> >> thoughts? >> >> -M >> >> [1] >> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >> >> >> >> >> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >>> solved... updating the spec >>> >>> On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>>> 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. >>>> >>>> This is the part I don't understand so sorry if I'm the only one being >>>> dense here. I believe that is basically what we decided to do yesterday, >>>> but, without that initial config, how do I make the initial request for the >>>> first page? Since the callback that the dev would provide isn't triggered >>>> until a successful read so that it can "build" the next/prev methods based >>>> on the response, how do I make that first request? >>>> >>>>> >>>>> Any thoughts? >>>>> >>>>> -M >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Any news on this ? >>>>>> >>>>>> -Matthias >>>>>> >>>>>>> >>>>>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman <supittma(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> based on today's IRC and mailing list discussions, I have polished >>>>>>>>> the >>>>>>>>> client side paging spec: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>>>>>>> >>>>>>>>> Please review the document! >>>>>>>>> >>>>>>>>> Cheers! >>>>>>>>> Matthias >>>>>>>>> >>>>>>>> +1, let's see how it works in actual implementation! >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/18/2013 09:54 AM, Matthias Wessendorf wrote: > On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> +1 to 1) and 2) under the Pipe creation but also 3) , because if one has a >> custom impl for a pipe , he probably needs it for each read > > Actually.... since NEXT does change the offset (from > https://gist.github.com/4537431): > > My current "page" is "https://localhost/demo/cars?offset=20&limit=10" > > This means I get something like for next/prev: > <https://localhost/demo/cars?offset=10&limit=10>; rel="previous", > <https://localhost/demo/cars?offset=30&limit=10>; rel="next", > > > So... for iOS... the [next]; (or previous) would INTERNALLY do this: > > [_pipe readWithFilter:^(id<AGFilterConfig> config) { > [config setLimit:_limit]; > [config setOffset:_offset]; // got increased before > > } success:success failure:failure]; > > So... I think this is already impl detail, but when there ARE no > meta-information for NEXT/PREV available, > the user has to maintain that himself.... so passing the (updated) > parameter provider on the read is nice.... > > Christos and I tend to do that for iOS. I guess Summers will be on the > same page (haha) with his Android code > > -M Tthat all sounds good. > >> Okay for PipeConfig.updateParameterProvider() but he should also be able to >> pass anytime through the read() to reconfigure , no ? doesn't hurt to have >> many options to reconfigure IMO >> >> Just a last remark on the "locations" name : metadataLocation and >> pagingLocation are not enough clear to me to see what's coming in and out, >> as suggested on IRC : metadataLocationResponse and metadataLocationRequest ? >> >> >> >> >> On Fri, Jan 18, 2013 at 3:38 PM, Matthias Wessendorf <matzew(a)apache.org > >> wrote: >>> Looking at [1] >>> >>> >>> There is ONE detail left... >>> >>> The paging "config" contains the following settings: >>> 1) locations: >>> - metadataLocation >>> - pagingLocation >>> 2) param provider: >>> - my custom impl (like in https://gist.github.com/4564403#comment-732025) >>> OR >>> - default (limit + offset) >>> 3) web linking: >>> - nextIdentifier >>> - previousIdentifier >>> >>> >>> Now... where to put these options? On the pipe, or on the actual >>> "paging read" (e.g. readWithFilter....). >>> >>> I can see that 1) and 3) are nice on the umbrella Pipe >>> definiton/creation. I can also see that it's OK to "install" a "param >>> provider" on the pipe as well... >>> >>> If the "params" changes (for whatever reason), there could be a >>> "PipeConfig.updateParameterProvider()" hook.... >>> >>> I also think..... the parameter provider can be defined on the actual >>> read (get request).... >>> >>> thoughts? >>> >>> -M >>> >>> [1] >>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>> >>> >>> >>> >>> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf < matzew(a)apache.org&gt; >>> wrote: >>>> solved... updating the spec >>>> >>>> On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>> wrote: >>>>> >>>>>> 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. >>>>> This is the part I don't understand so sorry if I'm the only one being >>>>> dense here. I believe that is basically what we decided to do yesterday, >>>>> but, without that initial config, how do I make the initial request for the >>>>> first page? Since the callback that the dev would provide isn't triggered >>>>> until a successful read so that it can "build" the next/prev methods based >>>>> on the response, how do I make that first request? >>>>> >>>>>> Any thoughts? >>>>>> >>>>>> -M >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Any news on this ? >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman < supittma(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> based on today's IRC and mailing list discussions, I have polished >>>>>>>>>> the >>>>>>>>>> client side paging spec: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>>>>>>>> >>>>>>>>>> Please review the document! >>>>>>>>>> >>>>>>>>>> Cheers! >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>> +1, let's see how it works in actual implementation! >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> 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