+1<br><br><div class="gmail_quote">On Fri, Jan 18, 2013 at 4:05 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/18/2013 09:54 AM, Matthias Wessendorf wrote:<br>
> On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>> wrote:<br>
>> +1 to 1) and 2) under the Pipe creation but also 3) , because if one has a<br>
>> custom impl for a pipe , he probably needs it for each read<br>
><br>
> Actually.... since NEXT does change the offset (from<br>
> <a href="https://gist.github.com/4537431" target="_blank">https://gist.github.com/4537431</a>):<br>
><br>
> My current "page" is "<a href="https://localhost/demo/cars?offset=20&limit=10" target="_blank">https://localhost/demo/cars?offset=20&limit=10</a>"<br>
><br>
> This means I get something like for next/prev:<br>
> <<a href="https://localhost/demo/cars?offset=10&limit=10" target="_blank">https://localhost/demo/cars?offset=10&limit=10</a>>; rel="previous",<br>
> <<a href="https://localhost/demo/cars?offset=30&limit=10" target="_blank">https://localhost/demo/cars?offset=30&limit=10</a>>; rel="next",<br>
><br>
><br>
> So... for iOS... the [next]; (or previous) would INTERNALLY do this:<br>
><br>
> [_pipe readWithFilter:^(id<AGFilterConfig> config) {<br>
> [config setLimit:_limit];<br>
> [config setOffset:_offset]; // got increased before<br>
><br>
> } success:success failure:failure];<br>
><br>
> So... I think this is already impl detail, but when there ARE no<br>
> meta-information for NEXT/PREV available,<br>
> the user has to maintain that himself.... so passing the (updated)<br>
> parameter provider on the read is nice....<br>
><br>
> Christos and I tend to do that for iOS. I guess Summers will be on the<br>
> same page (haha) with his Android code<br>
><br>
> -M<br>
</div>Tthat all sounds good.<br>
<div class="HOEnZb"><div class="h5">><br>
>> Okay for PipeConfig.updateParameterProvider() but he should also be able to<br>
>> pass anytime through the read() to reconfigure , no ? doesn't hurt to have<br>
>> many options to reconfigure IMO<br>
>><br>
>> Just a last remark on the "locations" name : metadataLocation and<br>
>> pagingLocation are not enough clear to me to see what's coming in and out,<br>
>> as suggested on IRC : metadataLocationResponse and metadataLocationRequest ?<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Jan 18, 2013 at 3:38 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
>> wrote:<br>
>>> Looking at [1]<br>
>>><br>
>>><br>
>>> There is ONE detail left...<br>
>>><br>
>>> The paging "config" contains the following settings:<br>
>>> 1) locations:<br>
>>> - metadataLocation<br>
>>> - pagingLocation<br>
>>> 2) param provider:<br>
>>> - my custom impl (like in <a href="https://gist.github.com/4564403#comment-732025" target="_blank">https://gist.github.com/4564403#comment-732025</a>)<br>
>>> OR<br>
>>> - default (limit + offset)<br>
>>> 3) web linking:<br>
>>> - nextIdentifier<br>
>>> - previousIdentifier<br>
>>><br>
>>><br>
>>> Now... where to put these options? On the pipe, or on the actual<br>
>>> "paging read" (e.g. readWithFilter....).<br>
>>><br>
>>> I can see that 1) and 3) are nice on the umbrella Pipe<br>
>>> definiton/creation. I can also see that it's OK to "install" a "param<br>
>>> provider" on the pipe as well...<br>
>>><br>
>>> If the "params" changes (for whatever reason), there could be a<br>
>>> "PipeConfig.updateParameterProvider()" hook....<br>
>>><br>
>>> I also think..... the parameter provider can be defined on the actual<br>
>>> read (get request)....<br>
>>><br>
>>> thoughts?<br>
>>><br>
>>> -M<br>
>>><br>
>>> [1]<br>
>>> <a href="https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown" target="_blank">https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
>>> wrote:<br>
>>>> solved... updating the spec<br>
>>>><br>
>>>> On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
>>>>> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>>> On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf<br>
>>>>>> <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
>>>>>>>> My suggestion is to name these two parameters something more generic<br>
>>>>>>>> like locator/count where locator=page/offset and count=limit/perPage. Then<br>
>>>>>>>> in our configs we would provide these options:<br>
>>>>>>>><br>
>>>>>>>> pagingType {String} - determines the paging method to be used in<br>
>>>>>>>> calculating next page, etc. and could be either "offset" or "page", default<br>
>>>>>>>> "offset"<br>
>>>>>>>> locatorParam {String} - locator parameter name, default "offset"<br>
>>>>>>>> locatorValue {Number} - page index or offset<br>
>>>>>>>> locatorIdentifier {String} - the locator identifier name, default<br>
>>>>>>>> "AG-Paging-Offset"<br>
>>>>>>>> countParam {String} - count parameter name, default "limit"<br>
>>>>>>>> countValue {Number} - items per page<br>
>>>>>>>> countIdentifier {String} - the count identifier name, default<br>
>>>>>>>> "AG-Paging-Limit"<br>
>>>>>>>><br>
>>>>>>>> Thoughts?<br>
>>>>>><br>
>>>>>> OK.... I agree that you raised a valid concern, regarding that the<br>
>>>>>> client needs to indicate whether paging information is sent as<br>
>>>>>> headers, as query parameters, or as body data.<br>
>>>>>><br>
>>>>>><br>
>>>>>> But I still am not so sure if the above args are all really needed, a<br>
>>>>>> ton of cfg params make it a bit fishy.<br>
>>>>>> How about, using the following as a default "parameter provider"<br>
>>>>>> - offset (which sets the offset of the first element that should be<br>
>>>>>> included in the returned collection)<br>
>>>>>> - limit (the number of results that should be listed on a page)<br>
>>>>>><br>
>>>>>> OK.<br>
>>>>>><br>
>>>>>> Now if a user wants/needs to provide a different parameter schema<br>
>>>>>> (imagine his/her lame server requires/supports "page", "perPage" and<br>
>>>>>> "sorting"):<br>
>>>>>> The developer could just create a custom impl (iOS: block, Java:<br>
>>>>>> anonymus class impl of an interface, JS: callback function) and pass<br>
>>>>>> it to the "paging request".<br>
>>>>>><br>
>>>>>> that way the dev. could even add a ton of more params (if the lame<br>
>>>>>> backend requires that).<br>
>>>>>><br>
>>>>>> since the pipe (or the paging request) knows whether the paging<br>
>>>>>> information is sent as headers, as query parameters, or as body data,<br>
>>>>>> it would just "serialize" the give "param provider" into the actual<br>
>>>>>> location.<br>
>>>>> This is the part I don't understand so sorry if I'm the only one being<br>
>>>>> dense here. I believe that is basically what we decided to do yesterday,<br>
>>>>> but, without that initial config, how do I make the initial request for the<br>
>>>>> first page? Since the callback that the dev would provide isn't triggered<br>
>>>>> until a successful read so that it can "build" the next/prev methods based<br>
>>>>> on the response, how do I make that first request?<br>
>>>>><br>
>>>>>> Any thoughts?<br>
>>>>>><br>
>>>>>> -M<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>> Any news on this ?<br>
>>>>>>><br>
>>>>>>> -Matthias<br>
>>>>>>><br>
>>>>>>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman <<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>><br>
>>>>>>>> wrote:<br>
>>>>>>>><br>
>>>>>>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote:<br>
>>>>>>>>>> Hi,<br>
>>>>>>>>>><br>
>>>>>>>>>> based on today's IRC and mailing list discussions, I have polished<br>
>>>>>>>>>> the<br>
>>>>>>>>>> client side paging spec:<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> <a href="https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown" target="_blank">https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/specs/abstract_aerogear-client-paging.markdown</a><br>
>>>>>>>>>><br>
>>>>>>>>>> Please review the document!<br>
>>>>>>>>>><br>
>>>>>>>>>> Cheers!<br>
>>>>>>>>>> Matthias<br>
>>>>>>>>>><br>
>>>>>>>>> +1, let's see how it works in actual implementation!<br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Matthias Wessendorf<br>
>>>>>>><br>
>>>>>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>>>>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>>>>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Matthias Wessendorf<br>
>>>>>><br>
>>>>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>>>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>>>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>>>>> _______________________________________________<br>
>>>>>> aerogear-dev mailing list<br>
>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> aerogear-dev mailing list<br>
>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Matthias Wessendorf<br>
>>>><br>
>>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>><br>
>>><br>
>>> --<br>
>>> Matthias Wessendorf<br>
>>><br>
>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
><br>
><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br>