I've hit one small snag. If the paging metadata is returned in the body, it would probably be useful for the developer to be able to specify a "paging container" and/or a "results container" since each of those pieces of information would probably be encapsulated from the other in any sane server implementation. I would suggest something like metadataContainer and dataContainer with defaults of "paging" and "data" as defaults but I am totally flexible on those. Thoughts? _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Reposting from GMail because Red Hat account is blocked again] Thinking more, we could probably just keep the defaults undefined, that way they only define if they need them, otherwise the root of the response is assumed which would probably work better since for example, Twitter encapsulates the data but the paging is at the root of the response.

On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > I've hit one small snag. If the paging metadata is returned in the body, it would probably be useful for the developer to be able to specify a "paging container" and/or a "results container" since each of those pieces of information would probably be encapsulated from the other in any sane server implementation. I would suggest something like metadataContainer and dataContainer with defaults of "paging" and "data" as defaults but I am totally flexible on those. > > Thoughts? > _______________________________________________ > 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

Interesting point Kris ! Not sure how we can provide a simple and robust solution that works for all the cases. Maybe as you said, we follow a convention, that the info is at the root and otherwise the developer could use a custom function (as we do for sending paging info) to consume lpaging metadata.

Seb On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers(a)gmail.com&gt; > wrote: > > [Reposting from GMail because Red Hat account is blocked again] > > Thinking more, we could probably just keep the defaults undefined, that > > way they only define if they need them, otherwise the root of the response > > is assumed which would probably work better since for example, Twitter > > encapsulates the data but the paging is at the root of the response. > > > > Ah... ok, thanks for the example - I ran into that yesterday evening > as well, when testing parsing of the TW info... > > Here is, I think, what you define "result container" > { > "next_page": "some value..", > "prev_page": "moar value...", > ... > more 'flat' data.... > ... > } > > There is a flat JSON response, that has the desired values at the root > level of the response. > > Yesterday, I was wondering if there are server that do a more > structured (think Java/XML) response > { > "metadata": { > "next_page": "some value..", > "prev_page": "moar value...", > // other metadata.... > }, > /// more structured results... > } > > So yeah... that does not work, right now... But what happens if they > have even a bit deeper nesting (you never know why...).... I am now > just thinking XPath :) but I see your point, since I had that same > thought yesterday, after parsing twitters bits. > > > -M > > > > > On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > > >> I've hit one small snag. If the paging metadata is returned in the > >> body, it would probably be useful for the developer to be able to specify a > >> "paging container" and/or a "results container" since each of those pieces > >> of information would probably be encapsulated from the other in any sane > >> server implementation. I would suggest something like metadataContainer and > >> dataContainer with defaults of "paging" and "data" as defaults but I am > >> totally flexible on those. > >> > >> Thoughts? > >> _______________________________________________ > >> 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

On Jan 22, 2013, at 3:50 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Tue, Jan 22, 2013 at 10:37 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> Interesting point Kris ! >> Not sure how we can provide a simple and robust solution that works for all >> the cases. Maybe as you said, we follow a convention, that the info is at >> the root and otherwise the developer could use a custom function (as we do >> for sending paging info) to consume lpaging metadata. > > yeah - something like a "provider" (function would work). I think I can get on board with that. > > We can't catch every server API :) > >> Seb >> >> >> On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >>> >>> On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers(a)gmail.com&gt; >>> wrote: >>>> [Reposting from GMail because Red Hat account is blocked again] >>>> Thinking more, we could probably just keep the defaults undefined, that >>>> way they only define if they need them, otherwise the root of the response >>>> is assumed which would probably work better since for example, Twitter >>>> encapsulates the data but the paging is at the root of the response. >>>> >>> >>> Ah... ok, thanks for the example - I ran into that yesterday evening >>> as well, when testing parsing of the TW info... >>> >>> Here is, I think, what you define "result container" >>> { >>> "next_page": "some value..", >>> "prev_page": "moar value...", >>> ... >>> more 'flat' data.... >>> ... >>> } >>> >>> There is a flat JSON response, that has the desired values at the root >>> level of the response. >>> >>> Yesterday, I was wondering if there are server that do a more >>> structured (think Java/XML) response >>> { >>> "metadata": { >>> "next_page": "some value..", >>> "prev_page": "moar value...", >>> // other metadata.... >>> }, >>> /// more structured results... >>> } >>> >>> So yeah... that does not work, right now... But what happens if they >>> have even a bit deeper nesting (you never know why...).... I am now >>> just thinking XPath :) but I see your point, since I had that same >>> thought yesterday, after parsing twitters bits. >>> >>> >>> -M >>> >>> >>> >>>> On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>>> I've hit one small snag. If the paging metadata is returned in the >>>>> body, it would probably be useful for the developer to be able to specify a >>>>> "paging container" and/or a "results container" since each of those pieces >>>>> of information would probably be encapsulated from the other in any sane >>>>> server implementation. I would suggest something like metadataContainer and >>>>> dataContainer with defaults of "paging" and "data" as defaults but I am >>>>> totally flexible on those. >>>>> >>>>> Thoughts? >>>>> _______________________________________________ >>>>> 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

On Tue, Jan 22, 2013 at 4:10 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > So should we assume paging metadata is at the root for now yeah ... > and data is under a "results" key? (Like Twitter) for iOS not a bit deal, we deliver the entire reponse :)

> > On Jan 22, 2013, at 8:56 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jan 22, 2013, at 3:50 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> On Tue, Jan 22, 2013 at 10:37 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> Interesting point Kris ! >>>> Not sure how we can provide a simple and robust solution that works for all >>>> the cases. Maybe as you said, we follow a convention, that the info is at >>>> the root and otherwise the developer could use a custom function (as we do >>>> for sending paging info) to consume lpaging metadata. >>> >>> yeah - something like a "provider" (function would work). >> >> I think I can get on board with that. >>> >>> We can't catch every server API :) >>> >>>> Seb >>>> >>>> >>>> On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>>> >>>>> On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers(a)gmail.com&gt; >>>>> wrote: >>>>>> [Reposting from GMail because Red Hat account is blocked again] >>>>>> Thinking more, we could probably just keep the defaults undefined, that >>>>>> way they only define if they need them, otherwise the root of the response >>>>>> is assumed which would probably work better since for example, Twitter >>>>>> encapsulates the data but the paging is at the root of the response. >>>>>> >>>>> >>>>> Ah... ok, thanks for the example - I ran into that yesterday evening >>>>> as well, when testing parsing of the TW info... >>>>> >>>>> Here is, I think, what you define "result container" >>>>> { >>>>> "next_page": "some value..", >>>>> "prev_page": "moar value...", >>>>> ... >>>>> more 'flat' data.... >>>>> ... >>>>> } >>>>> >>>>> There is a flat JSON response, that has the desired values at the root >>>>> level of the response. >>>>> >>>>> Yesterday, I was wondering if there are server that do a more >>>>> structured (think Java/XML) response >>>>> { >>>>> "metadata": { >>>>> "next_page": "some value..", >>>>> "prev_page": "moar value...", >>>>> // other metadata.... >>>>> }, >>>>> /// more structured results... >>>>> } >>>>> >>>>> So yeah... that does not work, right now... But what happens if they >>>>> have even a bit deeper nesting (you never know why...).... I am now >>>>> just thinking XPath :) but I see your point, since I had that same >>>>> thought yesterday, after parsing twitters bits. >>>>> >>>>> >>>>> -M >>>>> >>>>> >>>>> >>>>>> On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>> >>>>>>> I've hit one small snag. If the paging metadata is returned in the >>>>>>> body, it would probably be useful for the developer to be able to specify a >>>>>>> "paging container" and/or a "results container" since each of those pieces >>>>>>> of information would probably be encapsulated from the other in any sane >>>>>>> server implementation. I would suggest something like metadataContainer and >>>>>>> dataContainer with defaults of "paging" and "data" as defaults but I am >>>>>>> totally flexible on those. >>>>>>> >>>>>>> Thoughts? >>>>>>> _______________________________________________ >>>>>>> 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 > > > _______________________________________________ > 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

On Tue, Jan 22, 2013 at 4:17 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jan 22, 2013, at 9:14 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> On Tue, Jan 22, 2013 at 4:10 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> So should we assume paging metadata is at the root >> >> for now yeah ... >> >>> and data is under a "results" key? (Like Twitter) >> >> for iOS not a bit deal, we deliver the entire reponse :) > > Hmmm, good point. JS has always done this too, it's just always been only data returned. I will continue to just return the entire object as well and the dev can pull the data out. That way, we don't need to worry about where it is, just the paging metadata. > which is solved (when at root level :-) - which is fine for now - OK ?

>> >>> >>> On Jan 22, 2013, at 8:56 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Jan 22, 2013, at 3:50 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>>> On Tue, Jan 22, 2013 at 10:37 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>> Interesting point Kris ! >>>>>> Not sure how we can provide a simple and robust solution that works for all >>>>>> the cases. Maybe as you said, we follow a convention, that the info is at >>>>>> the root and otherwise the developer could use a custom function (as we do >>>>>> for sending paging info) to consume lpaging metadata. >>>>> >>>>> yeah - something like a "provider" (function would work). >>>> >>>> I think I can get on board with that. >>>>> >>>>> We can't catch every server API :) >>>>> >>>>>> Seb >>>>>> >>>>>> >>>>>> On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>>> wrote: >>>>>>> >>>>>>> On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers(a)gmail.com&gt; >>>>>>> wrote: >>>>>>>> [Reposting from GMail because Red Hat account is blocked again] >>>>>>>> Thinking more, we could probably just keep the defaults undefined, that >>>>>>>> way they only define if they need them, otherwise the root of the response >>>>>>>> is assumed which would probably work better since for example, Twitter >>>>>>>> encapsulates the data but the paging is at the root of the response. >>>>>>>> >>>>>>> >>>>>>> Ah... ok, thanks for the example - I ran into that yesterday evening >>>>>>> as well, when testing parsing of the TW info... >>>>>>> >>>>>>> Here is, I think, what you define "result container" >>>>>>> { >>>>>>> "next_page": "some value..", >>>>>>> "prev_page": "moar value...", >>>>>>> ... >>>>>>> more 'flat' data.... >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> There is a flat JSON response, that has the desired values at the root >>>>>>> level of the response. >>>>>>> >>>>>>> Yesterday, I was wondering if there are server that do a more >>>>>>> structured (think Java/XML) response >>>>>>> { >>>>>>> "metadata": { >>>>>>> "next_page": "some value..", >>>>>>> "prev_page": "moar value...", >>>>>>> // other metadata.... >>>>>>> }, >>>>>>> /// more structured results... >>>>>>> } >>>>>>> >>>>>>> So yeah... that does not work, right now... But what happens if they >>>>>>> have even a bit deeper nesting (you never know why...).... I am now >>>>>>> just thinking XPath :) but I see your point, since I had that same >>>>>>> thought yesterday, after parsing twitters bits. >>>>>>> >>>>>>> >>>>>>> -M >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> I've hit one small snag. If the paging metadata is returned in the >>>>>>>>> body, it would probably be useful for the developer to be able to specify a >>>>>>>>> "paging container" and/or a "results container" since each of those pieces >>>>>>>>> of information would probably be encapsulated from the other in any sane >>>>>>>>> server implementation. I would suggest something like metadataContainer and >>>>>>>>> dataContainer with defaults of "paging" and "data" as defaults but I am >>>>>>>>> totally flexible on those. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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

On Tue, Jan 22, 2013 at 4:20 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > Not sure what you mean. Are you saying you aren't going to implement the provider right now? Yes, when the paging is at root level (-> twitter), we are good. > I think that is something that should be in 1.0, IMO. Sure, if there is time, it can come in after M8?

-M -- 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

On 01/22/2013 11:08 AM, Matthias Wessendorf wrote: > On Tue, Jan 22, 2013 at 4:20 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> Not sure what you mean. Are you saying you aren't going to implement the provider right now? > Yes, when the paging is at root level (-> twitter), we are good. > >> I think that is something that should be in 1.0, IMO. > Sure, if there is time, it can come in after M8? > > > -M > It may be enough to include in PipeConfig a "resultPath" String which is the dotted path to the JSON result. Then we just use the nextIdentified/previousIdentifier fields in the spec to get the rest.

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I've hit one small snag. If the paging metadata is returned in the body, it would probably be useful for the developer to be able to specify a "paging container" and/or a "results container" since each of those pieces of information would probably be encapsulated from the other in any sane server implementation. I would suggest something like metadataContainer and dataContainer with defaults of "paging" and "data" as defaults but I am totally flexible on those.

Thoughts? _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev