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

Summers Pittman supittma at redhat.com
Fri Jan 18 13:17:09 EST 2013 


----- Original Message -----
| From: "Matthias Wessendorf" <matzew at apache.org>
| To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
| Sent: Friday, January 18, 2013 1:07:40 PM
| Subject: Re: [aerogear-dev] Final version (hopefully) (was: Re: Client side Paging Spec)
| 
| OK...
| 
| based on that, I think this one is the final outcome:
| 
| 
| https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown
| 
| Feel free to address concerns!
| 
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#default-parameter-providers

The type of offsetValue should not be an int.  It should be typeless.

| 
| -M
| 
| 
| 
| On Fri, Jan 18, 2013 at 6:59 PM, Kris Borchers <kris at redhat.com>
| wrote:
| >
| > On Jan 18, 2013, at 11:54 AM, Matthias Wessendorf
| > <matzew at apache.org> wrote:
| >
| >> On Fri, Jan 18, 2013 at 6:36 PM, Kris Borchers <kris at redhat.com>
| >> wrote:
| >>>
| >>> On Jan 18, 2013, at 11:26 AM, Matthias Wessendorf
| >>> <matzew at apache.org> wrote:
| >>>
| >>>> On Fri, Jan 18, 2013 at 5:53 PM, Kris Borchers <kris at redhat.com>
| >>>> wrote:
| >>>>> A couple of comments:
| >>>>>
| >>>>> In
| >>>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#request--and-pipe--level
| >>>>>
| >>>>> "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/specs/abstract_aerogear-client-paging.markdown#default-parameter-providers
| >>>>>
| >>>>> 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/specs/abstract_aerogear-client-paging.markdown#pipe-level
| >>
| >> 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/specs/abstract_aerogear-client-paging.markdown#methods
| >>>>>
| >>>>> "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 at apache.org> wrote:
| >>>>>
| >>>>> Published the lastest version:
| >>>>>
| >>>>> https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown#the-paging-configuration
| >>>>>
| >>>>> PS: the file name sucks, but that's not important ... :)
| >>>>>
| >>>>> On Fri, Jan 18, 2013 at 4:12 PM, Douglas Campos <qmx at qmx.me>
| >>>>> 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 at 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 at lists.jboss.org
| >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
| >>>>>
| >>>>>
| >>>>>
| >>>>> _______________________________________________
| >>>>> aerogear-dev mailing list
| >>>>> aerogear-dev at 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 at lists.jboss.org
| >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
| >>>
| >>>
| >>> _______________________________________________
| >>> aerogear-dev mailing list
| >>> aerogear-dev at 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 at lists.jboss.org
| >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
| >
| >
| > _______________________________________________
| > aerogear-dev mailing list
| > aerogear-dev at 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 at lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
|

More information about the aerogear-dev mailing list