Re: [aerogear-dev] Final version (hopefully) (was: Re: Client side Paging Spec)

On Jan 18, 2013, at 11:54 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Fri, Jan 18, 2013 at 6:36 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> On Jan 18, 2013, at 11:26 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> On Fri, Jan 18, 2013 at 5:53 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> A couple of comments: >>>> >>>> In >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>> >>>> "The Pipe is responsible to maintain the paging requests (e.g.next or >>>> previous), by using the given identifiers." >>>> >>>> I thought some of our recent changes were so that the pipe was not >>>> maintaining those but there were in fact part of the response and the dev >>>> would have to use them via the response object, not the pipe (though the >>>> actual read() would happen in the pipe with a config passed via next or >>>> previous). Not sure of the best way to word this but seems confusing as is. >>> >>> I mean, in order to simply say next(); the value for the offset on the >>> "rel=next;" needs to be applied >>> to the NEXT request, right ? I am trying to say that the pipe does >>> that. Why the pipe? Well, the read() is a method >>> on the pipe.... so, for me (OO world) when the read() uses that >>> information, the pipe somewhat does it. Makes sense >>> >>> If yes, can you update the above with "proper" English ? >> >> I'll take a look. > > Thanks! > > >>>> In >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>> >>>> I am still not a fan of calling the default params offset* and limit*. My >>>> concern is that if my app doesn't use offset, it would be confusing to me to >>>> set offsetIdentifier to "page" and offsetValue to 1 because I am using >>>> paging and my pages start at 1. When someone looks at that code, is it an >>>> offset of 1 or page 1 assuming I don't know the inner workings of the paging >>>> implementation. >>> >>> actually the "AG-Paging-Offset/Limit" RESPONSE headers have been >>> removed from the reponse. >> >> That's fine for us but the clients still need to work with any random header the server decides to send as paging info so somewhere this needs to be customizable just like the params. >> Not all servers are going to follow the Web Linking standard (RFC 5988) and we still need to work with them. > > Correct. Please see: > https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... > > If you say: > setMetadataLocation("content"); // reponsebody > setNextIdentifier("twitter-blah-next-json-key"); > setPreviousIdentifier("twitter-blah-prev-json-key"); > > > So, that works - > > I guess... for the 'setMetadataLocation' we need another param: > -header (if the IDENTIFIERS are defined in the header) > -content (if the IDENTIFIERS are defined in the body) // heck, should > it be 'body' instead of content? > -webLinking (if the IDENTIFIERS are defined using rfc5988) // OF > COURSE, the name of the arg, is NOT final - just the concept > > For an alterntive "rel" name... it would, than, look like: > setMetadataLocation("webLinking"); // reponsebody > setPreviousIdentifier("twPrev"); // our default is 'previous' > > Makes sense ? YES!!! \o/ > > >>> >>> Custom params -> "param provider" (which is up the the actual impl) >>> >>> >>>> >>>> Also, what happens if I want to just call it something else because those >>>> names confuse me so I create my own page param via the parameter provider. >>>> Since I didn't do anything with offsetValue and offsetIdentifier, now my >>>> request might look like cars?page=2&offset=0 because the default was added >>>> in on top of my values. Again, maybe I'm missing something but I think a >>>> rename of those options to something with less "meaning" would help prevent >>>> future confusion. >>> >>> if your server has no offset, than provide a "param provider". >> So what you're saying is if a param provider is used, the defaults are completely thrown out? If that's the case then this is fine. > > yup, that's how the iOS lib will implement this spec. > > >>> If you start sending bogus bits to the server... well, you asked for trouble… >> Agreed, I just thought it would happen without the dev actually wanting it. Based on the previous statement though, this is not an issue. > > \o/ > > -Matthias > >>> >>>> >>>> In >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>> >>>> "NOTE: When scrolling outside of the allowed range (e.g. invoking next on >>>> the last page), the server should return an empty list." >>>> >>>> We can't control what the server returns so 1) we shouldn't make this >>>> statement >>> >>> yes >>> >>>> and 2) the client libs should be able to handle any success >>>> response whether there is data or not and also any error response. >>> >>> thx - backed that into the spec >>> >>> >>> -Matthias >>> >>>> >>>> On Jan 18, 2013, at 10:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>> Published the lastest version: >>>> >>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe... >>>> >>>> PS: the file name sucks, but that's not important ... :) >>>> >>>> On Fri, Jan 18, 2013 at 4:12 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>>> >>>> On Fri, Jan 18, 2013 at 03:54:19PM +0100, Matthias Wessendorf wrote: >>>> >>>> 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 >>>> >>>> >>>> +1 here - totally makes sense :) >>>> >>>> -- qmx >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev