<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">OK, so here is where I stand. I don't think there is any way to have the API's match identically between JS and the others. It sounds like Android and iOS are getting closer to agreement but as they get closer, it seems they get further away from what makes sense for JS. Basically, anything that involves creating a new object to maintain paged pipes rather than just using any other pipe and overloading the read method to do paging doesn't make sense to me. IMO, JS should move forward with basically what was written up in the strawman as that feels like the best solution for JS.<div><br><div><div>On Jan 15, 2013, at 10:18 AM, Summers Pittman <<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/15/2013 08:45 AM, Sebastien Blanc
wrote:<br>
</div>
<blockquote cite="mid:CAD_dpu0dZceRqzoUWeOqQX2v_QfopR_2yQz7Zhmbv7qnSbhDqg@mail.gmail.com" type="cite">
<div>Just to summarize what have until now :</div>
<div><br>
</div>
<div>1. Kris's proposition: <a moz-do-not-send="true" href="https://gist.github.com/4531575">https://gist.github.com/4531575</a></div>
<div><br>
</div>
<div>2. Summers's proposition: <a moz-do-not-send="true" href="https://gist.github.com/4532661">https://gist.github.com/4532661</a></div>
<div><br>
</div>
<div>3. qmx's propositon: <a moz-do-not-send="true" href="https://gist.github.com/4538709">https://gist.github.com/4538709</a></div>
<div><br>
</div>
<div>4. Sebi's proposition<a moz-do-not-send="true" href="https://gist.github.com/4538725">https://gist.github.com/4538725</a></div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
I've just updated my proposition. PageContext is no longer and
thing and I've replaced it with a PagedList interface.<br>
<blockquote cite="mid:CAD_dpu0dZceRqzoUWeOqQX2v_QfopR_2yQz7Zhmbv7qnSbhDqg@mail.gmail.com" type="cite">
<div><br>
<br>
<div class="gmail_quote">On Tue, Jan 15, 2013 at 2:32 PM,
Matthias Wessendorf <span dir="ltr"><<a moz-do-not-send="true" href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</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 Tue, Jan 15, 2013 at 2:25 PM, Matthias
Wessendorf <<a moz-do-not-send="true" href="mailto:matzew@apache.org">matzew@apache.org</a>>
wrote:<br>
> I was wondering, if the result should be received on
every rquest,<br>
<br>
<br>
</div>
ideally on the callback..., to not block (at least in iOS
land, I<br>
would pass that "result set" on to the "success" block)<br>
<span class="HOEnZb"><font color="#888888"><br>
-M<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
><br>
> thx<br>
><br>
> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
<<a moz-do-not-send="true" href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>>
wrote:<br>
>> In the same spirit (inspired from<br>
>> <a moz-do-not-send="true" href="http://stackoverflow.com/questions/5412059/how-to-implement-general-pagination" target="_blank">http://stackoverflow.com/questions/5412059/how-to-implement-general-pagination</a>)<br>
>> :<br>
>><br>
>><br>
>> public interface PagedResult<T> {<br>
>><br>
>> PagedResult<T> next();<br>
>><br>
>> PagedResult<T> prev();<br>
>><br>
>> PagedResult<T> withOffset(int
offset);<br>
>><br>
>> PagedResult<T> withLimit(int limit);<br>
>><br>
>> List<T> result();<br>
>><br>
>> }<br>
>><br>
>><br>
>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos
<<a moz-do-not-send="true" href="mailto:qmx@qmx.me">qmx@qmx.me</a>>
wrote:<br>
>>><br>
>>> I'm not a fan of those PageContext objects
(remembers me of some wild-ass<br>
>>> ThreadLocals leaking all over)<br>
>>><br>
>>> My proposal for the paging aware APIs would
be something like this:<br>
>>><br>
>>> public interface PagedResult<T> {<br>
>>><br>
>>> List<T> next();<br>
>>><br>
>>> List<T> prev();<br>
>>><br>
>>> List<T> page(int offset, int
limit);<br>
>>><br>
>>> }<br>
>>><br>
>>> and the Async counterpart<br>
>>><br>
>>> public interface AsyncPagedResult<T>
{<br>
>>><br>
>>> void next(Callback<List<T>>
callback);<br>
>>><br>
>>> void prev(Callback<List<T>>
callback);<br>
>>><br>
>>> void page(int offset, int limit,
Callback<List<T>> callback);<br>
>>><br>
>>> public static interface
Callback<U> {<br>
>>> public void onResult(U result);<br>
>>> }<br>
>>> }<br>
>>><br>
>>> I don't like the idea of having a companion
object for holding the<br>
>>> pagination state.<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> -- qmx<br>
>>><br>
>>> On 15/01/2013, at 08:37, Matthias
Wessendorf <<a moz-do-not-send="true" href="mailto:matzew@apache.org">matzew@apache.org</a>>
wrote:<br>
>>><br>
>>> > Hi Summers,<br>
>>> ><br>
>>> ><br>
>>> > <a moz-do-not-send="true" href="https://gist.github.com/4532661" target="_blank">https://gist.github.com/4532661</a><br>
>>> ><br>
>>> > That is a way to do paging which keeps
Pipes immutable, uses<br>
>>> > readWithFilter, and doesn't impose any
(for convenient definitions of any)<br>
>>> > bookkeeping on the developer.<br>
>>> ><br>
>>> ><br>
>>> > from your Andorid gist:<br>
>>> ><br>
>>> > A) Once the response has been
received, the Pipe implementation will<br>
>>> > return a List of objects. If this List
instance is passed to<br>
>>> > Pipe.getPageContext the appropriate
PageContext will be returned<br>
>>> ><br>
>>> > Note: There is no 'return' - the
readWithFilter is void, instead a<br>
>>> > Callback is invoked (onSuccess(list)),
see Pipe.java<br>
>>> ><br>
>>> > B) The developer will receive from
readWithFilter() a List of object. If<br>
>>> > she passes this list into
Pipe.getPageContext(List result) she will receive<br>
>>> > the PageContext associated with this
result.<br>
>>> ><br>
>>> > Do you mean like:<br>
>>> ><br>
>>> > ...<br>
>>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {<br>
>>> ><br>
>>> ><br>
>>> > @Override<br>
>>> ><br>
>>> ><br>
>>> > public void onSuccess(List<Data>
data) {<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > // get the PageContext:<br>
>>> ><br>
>>> ><br>
>>> > PageContext ctx =
myPipe.getPageContext(data);<br>
>>> ><br>
>>> ><br>
>>> > ...<br>
>>> ><br>
>>> ><br>
>>> > }<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > @Override<br>
>>> ><br>
>>> ><br>
>>> > public void onFailure(Exception e) {<br>
>>> ><br>
>>> ><br>
>>> > }<br>
>>> > });<br>
>>> > Not sure about that.....<br>
>>> ><br>
>>> > But for iOS I am thinking about
passing in the PageContext into the<br>
>>> > closure/block of the readWithFilter,
like:<br>
>>> ><br>
>>> > -(void) readWithFilter:(void
(^)(id<AGFilterConfig> config)) config<br>
>>> ><br>
>>> ><br>
>>> > success:(void (^)(id listOfObjects, id
pageContext))success<br>
>>> ><br>
>>> ><br>
>>> > failure:(void (^)(NSError
*error))failure;<br>
>>> > A usage would look like:<br>
>>> ><br>
>>> > [pipe
readWithFilter:^(id<AGFilterConfig> config) {<br>
>>> ><br>
>>> ><br>
>>> > // set the filter args and override
the given defaults<br>
>>> ><br>
>>> ><br>
>>> > } success:^(id listOfObjects, id
pageContext) {<br>
>>> ><br>
>>> ><br>
>>> > // work with the listOfObjects
reponse.<br>
>>> ><br>
>>> ><br>
>>> > // for paging/query info, access the
given pagecontext,<br>
>>> ><br>
>>> ><br>
>>> > // of the CURRENT request<br>
>>> ><br>
>>> ><br>
>>> > ...<br>
>>> ><br>
>>> ><br>
>>> > } failure:^(NSError *error) {<br>
>>> ><br>
>>> ><br>
>>> > // handle errorz<br>
>>> ><br>
>>> ><br>
>>> > }];<br>
>>> > Any thoughts ?<br>
>>> ><br>
>>> > Not sure I like (or understand) the
Pipe.getPageContext(List result)<br>
>>> > call. Current mindset is that
thePageContext just (and only) belongs to the<br>
>>> > previous (executed) request... Not
sure I want to support something like<br>
>>> ><br>
>>> > // first call:<br>
>>> > List<SomeType> first;<br>
>>> > myPipe.readWithFilter(.....) // set
first inside of callback<br>
>>> > ...<br>
>>> > // second call:<br>
>>> > List<SomeType> second;<br>
>>> > myPipe.readWithFilter(.....) // set
second inside of callback<br>
>>> > ...<br>
>>> > // third call:<br>
>>> > List<SomeType> third;<br>
>>> > myPipe.readWithFilter(.....) // set
third inside of callback<br>
>>> > ...<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > /// A BIT LATER ....:<br>
>>> > myPipe.getPageContext(first);<br>
>>> ><br>
>>> ><br>
>>> > I am not sure if that
(myPipe.getPageContext(first);) is really desired<br>
>>> > (or would even easily work, as it
would need to store the "metadata").....<br>
>>> ><br>
>>> ><br>
>>> > Perhaps I am just wrong.<br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Matthias Wessendorf<br>
>>> ><br>
>>> > blog: <a moz-do-not-send="true" href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>> > sessions: <a moz-do-not-send="true" href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>> > twitter: <a moz-do-not-send="true" href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>> >
_______________________________________________<br>
>>> > aerogear-dev mailing list<br>
>>> > <a moz-do-not-send="true" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> > <a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true" 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>
>> aerogear-dev mailing list<br>
>> <a moz-do-not-send="true" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true" 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>
> Matthias Wessendorf<br>
><br>
> blog: <a moz-do-not-send="true" href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a moz-do-not-send="true" href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a moz-do-not-send="true" href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
<br>
<br>
--<br>
Matthias Wessendorf<br>
<br>
blog: <a moz-do-not-send="true" href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a moz-do-not-send="true" href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a moz-do-not-send="true" href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true" 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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote></div><br></div></body></html>