Hi, was there already some discussion (and proposal) for paging APIs on the client ? It would be nice if the public client API semantics are somewhat identical on the different platforms. (I guess it's a MUST :)) Any pointers to gists etc are welcome Thx -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

Just to mention it, the Header are on option, we could still return the metedata an links in the json. Perhaps with an extra query param to enable this addition. But I understand that we need to be able to handle headers also if that is what users choose. On 11 January 2013 13:46, Kris Borchers <kris(a)redhat.com&gt; wrote: > > There were some discussions a long time ago but I don't remember ever > coming to a conclusion on how paging should be implemented and I don't know > any links to gists off the top of my head. > > That being said, this and the Paging Demo thread have gotten me thinking > that though I thought JS was ready, I see it is not. I had not thought about > the metadata being in headers. Since we are abstracting away the HTTP > request, it may make it harder to get at that information without us > providing an API into it (well, maybe not for JS but it might be nice to > have a built in way to access that info). > > I think this deserves a more in-depth conversation than can happen in > e-mail. Anyone up for a hangout ASAP to iron out what we want for the client > APIs? This looks like it could get messy when trying to keep it flexible for > the developer, though, this does make a great case/example for how useful my > ideas for automatic client configuration come in. :) > > On Jan 11, 2013, at 5:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > Hi, > > > > was there already some discussion (and proposal) for paging APIs on the > > client ? > > > > It would be nice if the public client API semantics are somewhat > > identical on the different platforms. > > (I guess it's a MUST :)) > > > > Any pointers to gists etc are welcome > > > > Thx > > > > -- > > 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

>Do you think we "need" a "Link-Last"? (like github does)? We can add it if you like.

On 11 January 2013 14:11, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > Do you think we "need" a "Link-Last"? (like github does)? _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

want a JIRA ?

On Fri, Jan 11, 2013 at 2:15 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >>Do you think we "need" a "Link-Last"? (like github does)? > We can add it if you like. want a JIRA ? I personally like it << | < | > | >> first, back, next, last that's sometimes a common Web UI > > On 11 January 2013 14:11, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> Do you think we "need" a "Link-Last"? (like github does)? > > > > _______________________________________________ > 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 Fri, Jan 11, 2013 at 2:11 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > on my pagingContext, the next() would figure out how to use it for scrolling. > > I don't mind the headers, actually I like it. I *think* adding the meta data into the response would be wrong (cross cutting concerns)

-M > > ``` > Link-Previous: cars?page=0&page=4 > Link-First: cars?page=0&page=4 > MetaData-PerPage: 4 > MetaData-Page: 0 > Link-Next: cars?page=1&page=4 > > > Do you think we "need" a "Link-Last"? (like github does)? > > -M > > > On Fri, Jan 11, 2013 at 1:48 PM, Daniel Bevenius > <daniel.bevenius(a)gmail.com&gt; wrote: >> Just to mention it, the Header are on option, we could still return the >> metedata an links in the json. Perhaps with an extra query param to enable >> this addition. But I understand that we need to be able to handle headers >> also if that is what users choose. >> >> >> >> >> On 11 January 2013 13:46, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>> There were some discussions a long time ago but I don't remember ever >>> coming to a conclusion on how paging should be implemented and I don't know >>> any links to gists off the top of my head. >>> >>> That being said, this and the Paging Demo thread have gotten me thinking >>> that though I thought JS was ready, I see it is not. I had not thought about >>> the metadata being in headers. Since we are abstracting away the HTTP >>> request, it may make it harder to get at that information without us >>> providing an API into it (well, maybe not for JS but it might be nice to >>> have a built in way to access that info). >>> >>> I think this deserves a more in-depth conversation than can happen in >>> e-mail. Anyone up for a hangout ASAP to iron out what we want for the client >>> APIs? This looks like it could get messy when trying to keep it flexible for >>> the developer, though, this does make a great case/example for how useful my >>> ideas for automatic client configuration come in. :) >>> >>> On Jan 11, 2013, at 5:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> > Hi, >>> > >>> > was there already some discussion (and proposal) for paging APIs on the >>> > client ? >>> > >>> > It would be nice if the public client API semantics are somewhat >>> > identical on the different platforms. >>> > (I guess it's a MUST :)) >>> > >>> > Any pointers to gists etc are welcome >>> > >>> > Thx >>> > >>> > -- >>> > 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 >> > > > > -- > 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

On Jan 11, 2013, at 7:54 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Fri, Jan 11, 2013 at 2:11 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: on my pagingContext, the next() would figure out how to use it for scrolling. I don't mind the headers, actually I like it. I *think* adding the meta data into the response would be wrong (cross cutting concerns) http://search.twitter.com/search.json?q=aerogear

-M ``` Link-Previous: cars?page=0&page=4 Link-First: cars?page=0&page=4 MetaData-PerPage: 4 MetaData-Page: 0 Link-Next: cars?page=1&page=4 Do you think we "need" a "Link-Last"? (like github does)? -M On Fri, Jan 11, 2013 at 1:48 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: Just to mention it, the Header are on option, we could still return the metedata an links in the json. Perhaps with an extra query param to enable this addition. But I understand that we need to be able to handle headers also if that is what users choose. On 11 January 2013 13:46, Kris Borchers <kris(a)redhat.com&gt; wrote: There were some discussions a long time ago but I don't remember ever coming to a conclusion on how paging should be implemented and I don't know any links to gists off the top of my head. That being said, this and the Paging Demo thread have gotten me thinking that though I thought JS was ready, I see it is not. I had not thought about the metadata being in headers. Since we are abstracting away the HTTP request, it may make it harder to get at that information without us providing an API into it (well, maybe not for JS but it might be nice to have a built in way to access that info). I think this deserves a more in-depth conversation than can happen in e-mail. Anyone up for a hangout ASAP to iron out what we want for the client APIs? This looks like it could get messy when trying to keep it flexible for the developer, though, this does make a great case/example for how useful my ideas for automatic client configuration come in. :) On Jan 11, 2013, at 5:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hi, was there already some discussion (and proposal) for paging APIs on the client ? It would be nice if the public client API semantics are somewhat identical on the different platforms. (I guess it's a MUST :)) Any pointers to gists etc are welcome Thx -- 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 -- 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

On 01/11/2013 07:46 AM, Matthias Wessendorf wrote: Of course, sending simple request parameters to the server is easy, in every library (using Dan's CURL client example) ``` URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-de... curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4" ``` In terms of an client API, that wants to scroll through the cars (like in this demo), I was wondering if some "PagingContext" (or "ResultSet") API is needed... // issues a request with ?page=0&perPage=4 PagingContext pc = client.request(someCars...); // issues a request with ?page=0&perPage=4 pc.next() // issues a request with ?page=1&perPage=4 pc.next() // issues a request with ?page=0&perPage=4 pc.back() NOT sure, but IMO a little higher level abstraction would be nice, instead of having the end users of the "paging API" applying the values for 'page' and 'perPage' manually. Any thoughts? (Not sure if this has been brought up before) -M +1 for a higher level abstraction As far as how it will mesh with Pipe and such I am thinking https://gist.github.com/4511860

On Fri, Jan 11, 2013 at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hi, was there already some discussion (and proposal) for paging APIs on the client ? It would be nice if the public client API semantics are somewhat identical on the different platforms. (I guess it's a MUST :)) Any pointers to gists etc are welcome Thx -- 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/11/2013 07:46 AM, Matthias Wessendorf wrote: > Of course, sending simple request parameters to the server is easy, in > every library > > (using Dan's CURL client example) > > ``` > URL= > "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo" > > curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4" > ``` > > In terms of an client API, that wants to scroll through the cars (like > in this demo), I was wondering if some "PagingContext" (or > "ResultSet") API is needed... > > // issues a request with ?page=0&perPage=4 > PagingContext pc = client.request(someCars...); > > // issues a request with ?page=0&perPage=4 > pc.next() > > // issues a request with ?page=1&perPage=4 > pc.next() > > // issues a request with ?page=0&perPage=4 > pc.back() > > > NOT sure, but IMO a little higher level abstraction would be nice, > instead of having the end users of the "paging API" applying the > values for 'page' and 'perPage' manually. > > Any thoughts? (Not sure if this has been brought up before) > > -M > +1 for a higher level abstraction As far as how it will mesh with Pipe and such I am thinking https://gist.github.com/4511860 > > > On Fri, Jan 11, 2013 at 12:39 PM, Matthias Wessendorf > <matzew(a)apache.org&gt; > wrote: > >> Hi, >> >> was there already some discussion (and proposal) for paging APIs on the client ? >> >> It would be nice if the public client API semantics are somewhat >> identical on the different platforms. >> (I guess it's a MUST :)) >> >> Any pointers to gists etc are welcome >> >> Thx >> >> -- >> 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

What about returning a PagedList<T> (and using guava's ForwardingWhatever to decorate the list with the paging info)?

On 11/01/2013, at 14:14, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 01/11/2013 07:46 AM, Matthias Wessendorf wrote: >> Of course, sending simple request parameters to the server is easy, in >> every library >> >> (using Dan's CURL client example) >> >> ``` >> URL= >> "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo" >> >> curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4" >> ``` >> >> In terms of an client API, that wants to scroll through the cars (like >> in this demo), I was wondering if some "PagingContext" (or >> "ResultSet") API is needed... >> >> // issues a request with ?page=0&perPage=4 >> PagingContext pc = client.request(someCars...); >> >> // issues a request with ?page=0&perPage=4 >> pc.next() >> >> // issues a request with ?page=1&perPage=4 >> pc.next() >> >> // issues a request with ?page=0&perPage=4 >> pc.back() >> >> >> NOT sure, but IMO a little higher level abstraction would be nice, >> instead of having the end users of the "paging API" applying the >> values for 'page' and 'perPage' manually. >> >> Any thoughts? (Not sure if this has been brought up before) >> >> -M >> > +1 for a higher level abstraction > > As far as how it will mesh with Pipe and such I am thinking > > https://gist.github.com/4511860 > > > >> >> On Fri, Jan 11, 2013 at 12:39 PM, Matthias Wessendorf >> <matzew(a)apache.org&gt; >> wrote: >> >>> Hi, >>> >>> was there already some discussion (and proposal) for paging APIs on the client ? >>> >>> It would be nice if the public client API semantics are somewhat >>> identical on the different platforms. >>> (I guess it's a MUST :)) >>> >>> Any pointers to gists etc are welcome >>> >>> Thx >>> >>> -- >>> 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

On 01/11/2013 11:55 AM, Douglas Campos wrote: > What about returning a PagedList<T> (and using guava's ForwardingWhatever to decorate the list with the paging info)? > So something like PagedListExample? https://gist.github.com/d835d4a56d4d25e4ca9a > On 11/01/2013, at 14:14, Summers Pittman <supittma(a)redhat.com&gt; > wrote: > > >> On 01/11/2013 07:46 AM, Matthias Wessendorf wrote: >> >>> Of course, sending simple request parameters to the server is easy, in >>> every library >>> >>> (using Dan's CURL client example) >>> >>> ``` >>> URL= >>> >>> "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo" >>> >>> >>> curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4" >>> ``` >>> >>> In terms of an client API, that wants to scroll through the cars (like >>> in this demo), I was wondering if some "PagingContext" (or >>> "ResultSet") API is needed... >>> >>> // issues a request with ?page=0&perPage=4 >>> PagingContext pc = client.request(someCars...); >>> >>> // issues a request with ?page=0&perPage=4 >>> pc.next() >>> >>> // issues a request with ?page=1&perPage=4 >>> pc.next() >>> >>> // issues a request with ?page=0&perPage=4 >>> pc.back() >>> >>> >>> NOT sure, but IMO a little higher level abstraction would be nice, >>> instead of having the end users of the "paging API" applying the >>> values for 'page' and 'perPage' manually. >>> >>> Any thoughts? (Not sure if this has been brought up before) >>> >>> -M >>> >>> >> +1 for a higher level abstraction >> >> As far as how it will mesh with Pipe and such I am thinking >> >> >> https://gist.github.com/4511860 >> >> >> >> >> >>> >>> On Fri, Jan 11, 2013 at 12:39 PM, Matthias Wessendorf >>> >>> <matzew(a)apache.org&gt; >>> >>> wrote: >>> >>> >>>> Hi, >>>> >>>> was there already some discussion (and proposal) for paging APIs on the client ? >>>> >>>> It would be nice if the public client API semantics are somewhat >>>> identical on the different platforms. >>>> (I guess it's a MUST :)) >>>> >>>> Any pointers to gists etc are welcome >>>> >>>> Thx >>>> >>>> -- >>>> 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

On 01/11/2013 12:11 PM, Douglas Campos wrote: > Yeah, mixing the context (state) with the actual data. I like how simple and compact it makes things. Also it lets UI controls be much simpler, and it doesn't make us rely on something like WeakHashMap to clean up old contexts and such. IN either case, should the next() method block until Pipe.read()'s callback is called or should next consume a callback to be called after Pipe.read()'s callback is called?

> On 11/01/2013, at 15:06, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >> On 01/11/2013 11:55 AM, Douglas Campos wrote: >>> What about returning a PagedList<T> (and using guava's ForwardingWhatever to decorate the list with the paging info)? >>> >> So something like PagedListExample? >> https://gist.github.com/d835d4a56d4d25e4ca9a >>> On 11/01/2013, at 14:14, Summers Pittman <supittma(a)redhat.com&gt; >>> wrote: >>> >>> >>>> On 01/11/2013 07:46 AM, Matthias Wessendorf wrote: >>>> >>>>> Of course, sending simple request parameters to the server is easy, in >>>>> every library >>>>> >>>>> (using Dan's CURL client example) >>>>> >>>>> ``` >>>>> URL= >>>>> >>>>> "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo" >>>>> >>>>> >>>>> curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4" >>>>> ``` >>>>> >>>>> In terms of an client API, that wants to scroll through the cars (like >>>>> in this demo), I was wondering if some "PagingContext" (or >>>>> "ResultSet") API is needed... >>>>> >>>>> // issues a request with ?page=0&perPage=4 >>>>> PagingContext pc = client.request(someCars...); >>>>> >>>>> // issues a request with ?page=0&perPage=4 >>>>> pc.next() >>>>> >>>>> // issues a request with ?page=1&perPage=4 >>>>> pc.next() >>>>> >>>>> // issues a request with ?page=0&perPage=4 >>>>> pc.back() >>>>> >>>>> >>>>> NOT sure, but IMO a little higher level abstraction would be nice, >>>>> instead of having the end users of the "paging API" applying the >>>>> values for 'page' and 'perPage' manually. >>>>> >>>>> Any thoughts? (Not sure if this has been brought up before) >>>>> >>>>> -M >>>>> >>>>> >>>> +1 for a higher level abstraction >>>> >>>> As far as how it will mesh with Pipe and such I am thinking >>>> >>>> >>>> https://gist.github.com/4511860 >>>> >>>> >>>> >>>> >>>> >>>>> On Fri, Jan 11, 2013 at 12:39 PM, Matthias Wessendorf >>>>> >>>>> <matzew(a)apache.org&gt; >>>>> >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> was there already some discussion (and proposal) for paging APIs on the client ? >>>>>> >>>>>> It would be nice if the public client API semantics are somewhat >>>>>> identical on the different platforms. >>>>>> (I guess it's a MUST :)) >>>>>> >>>>>> Any pointers to gists etc are welcome >>>>>> >>>>>> Thx >>>>>> >>>>>> -- >>>>>> 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 > > _______________________________________________ > 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