<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">
<blockquote type="cite">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. </blockquote>
I'm confused. Your strawman creates extra pipes to maintain paged
states. The other proposals all use an overridden read method and
return a list which can be used to fetch different pages of data
(which is what it sounds like you want).<br>
<br>
<br>
On 01/15/2013 02:32 PM, Kris Borchers wrote:<br>
</div>
<blockquote
cite="mid:55FABB1C-1B08-46DE-962D-F0E3FE51A2AF@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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.</blockquote>
<blockquote
cite="mid:55FABB1C-1B08-46DE-962D-F0E3FE51A2AF@redhat.com"
type="cite">
<div><br>
<div>
<div>On Jan 15, 2013, at 10:18 AM, Summers Pittman <<a
moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</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>
</body>
</html>