On Fri, Apr 19, 2013 at 08:04:12AM -0400, Summers Pittman wrote: > So I've gotten a draft of the Pipe document up. > https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... > Some things I would like to call out and discuss include > 1 ) Pipe implementations should be thread safe. Specifically calls to > read, remove, and save should not change the internal state of a Pipe > object. +1 > 2 ) Pipeline.get is not guaranteed to always return the same instance > of a Pipe. This is something that came up with Android. Loaders are > 1:1 on the Activity or Fragment which references the Loader. > Therefore if a Pipe is reused between multiple Activities each one is > proxied in a different Loader. Why should we spec this? People counting on getting the same instance on year 2013...

> 3 ) A Pipe may proxy or delegate to a handler and this handler can be > exposed as a property. This is an Androidism as well. I think it can > probably be dropped from the spec but I wanted to see what other > people thought about it. +1 on dropping, this just adds complexity, and complex specs == boring read

> Some things which we may need to flesh out to make the spec more > complete are > 1 ) Authorization and Authentication. This is probably another > document We can probably just spec the Authentication/Authorization SPIs (very thin API surface)

> 2 ) A callback spec/definition. I am not sure whether this is a > separate document or not. Either way it should be short and sweet. Wdym? Could you elaborate more?

> 3 ) Platform implementation docs. A document with the code > examples/comparisons and notes where they may diverge from each other. > For instance in Android Callback is passed instances of the resource a > pipe represents, but in iOS and Javascript the callback is passed a > map of values. I didn't explicitly define this behavior in the spec. Isn't having the parallel usage examples enough? (kinda like we did on the paging spec)

On Mon, Apr 22, 2013 at 6:37 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: On 04/22/2013 12:45 AM, Douglas Campos wrote: > On Fri, Apr 19, 2013 at 08:04:12AM -0400, Summers Pittman wrote: >> So I've gotten a draft of the Pipe document up. >> >> https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... >> >> Some things I would like to call out and discuss include >> >> 1 ) Pipe implementations should be thread safe. Specifically calls to >> read, remove, and save should not change the internal state of a Pipe >> object. > +1 > >> 2 ) Pipeline.get is not guaranteed to always return the same instance >> of a Pipe. This is something that came up with Android. Loaders are >> 1:1 on the Activity or Fragment which references the Loader. >> Therefore if a Pipe is reused between multiple Activities each one is >> proxied in a different Loader. > Why should we spec this? People counting on getting the same instance on > year 2013... I just feel like it is one of those things that if we don't say up front people may rely on it. > >> 3 ) A Pipe may proxy or delegate to a handler and this handler can be >> exposed as a property. This is an Androidism as well. I think it can >> probably be dropped from the spec but I wanted to see what other >> people thought about it. > +1 on dropping, this just adds complexity, and complex specs == boring > read Will do. >> Some things which we may need to flesh out to make the spec more >> complete are >> >> 1 ) Authorization and Authentication. This is probably another >> document > We can probably just spec the Authentication/Authorization SPIs (very > thin API surface) So a separate doc then? > >> 2 ) A callback spec/definition. I am not sure whether this is a >> separate document or not. Either way it should be short and sweet. > Wdym? Could you elaborate more? We need to put down in writing Callback.onSuccess(result) and Callback.onFailure(cause) because it is used everywhere. > >> 3 ) Platform implementation docs. A document with the code >> examples/comparisons and notes where they may diverge from each other. >> For instance in Android Callback is passed instances of the resource a >> pipe represents, but in iOS and Javascript the callback is passed a >> map of values. I didn't explicitly define this behavior in the spec. > Isn't having the parallel usage examples enough? (kinda like we did on > the paging spec) Pretty much, I was just wondering if people were interested in having a Map behavior as a standard, leaving it to the implementation, or doing something else (like returning Headers and Body information) I agree, coming from java, the map thing _is_ weird :) but that's what a lot of folks do, in iOS land. I guess... we could spec this - but also keeping it abstract, not really sure, to be honest > _______________________________________________ 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 23 Apr 2013 07:34:03 AM EDT, Kris Borchers wrote: > Summers, > > I agree, great writeup. I just posted a line comment on one of the > commits but before I started doing that all over the place, I thought > I would ping you here first. Basically, I think there is too much > detail in much of this for it to be an abstract spec. At least in JS > land, many of the parameters passed to functions, the relationship of > Pipeline to Pipe and a number of other things are just very different > from Android. They even differ from iOS, but seem much closer there > than to Android. > > If you want, I can go line by line and point out these differences, or > would your rather just try to make a run through it and generalize it > a bit more without all of the noise? I am happy to go either way. I would prefer you call out specific instances. I checked the Javscript code and the spec describes what it does pretty closely. With the exception of handler (which will be excised on my next push) and the names I've chosen for certain things (what you call settings I call PipeConfig) I don't find anything terribly specific/not applicable to JS. > > Thanks, > Kris > > On Apr 23, 2013, at 4:03 AM, Matthias Wessendorf <matzew(a)apache.org > <mailto:matzew@apache.org>> wrote: > >> >> >> >> On Mon, Apr 22, 2013 at 6:37 PM, Summers Pittman <supittma(a)redhat.com >> <mailto:supittma@redhat.com>> wrote: >> >> On 04/22/2013 12:45 AM, Douglas Campos wrote: >>> On Fri, Apr 19, 2013 at 08:04:12AM -0400, Summers Pittman wrote: >>>> So I've gotten a draft of the Pipe document up. >>>> >>>> >> https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... >>>> >>>> Some things I would like to call out and discuss include >>>> >>>> 1 ) Pipe implementations should be thread safe. Specifically >> calls to >>>> read, remove, and save should not change the internal state of >> a Pipe >>>> object. >>> +1 >>> >>>> 2 ) Pipeline.get is not guaranteed to always return the same >> instance >>>> of a Pipe. This is something that came up with Android. >> Loaders are >>>> 1:1 on the Activity or Fragment which references the Loader. >>>> Therefore if a Pipe is reused between multiple Activities each >> one is >>>> proxied in a different Loader. >>> Why should we spec this? People counting on getting the same >> instance on >>> year 2013... >> I just feel like it is one of those things that if we don't say >> up front >> people may rely on it. >>> >>>> 3 ) A Pipe may proxy or delegate to a handler and this handler >> can be >>>> exposed as a property. This is an Androidism as well. I >> think it can >>>> probably be dropped from the spec but I wanted to see what other >>>> people thought about it. >>> +1 on dropping, this just adds complexity, and complex specs == >> boring >>> read >> Will do. >>>> Some things which we may need to flesh out to make the spec more >>>> complete are >>>> >>>> 1 ) Authorization and Authentication. This is probably another >>>> document >>> We can probably just spec the Authentication/Authorization SPIs >> (very >>> thin API surface) >> So a separate doc then? >>> >>>> 2 ) A callback spec/definition. I am not sure whether this is a >>>> separate document or not. Either way it should be short and >> sweet. >>> Wdym? Could you elaborate more? >> We need to put down in writing Callback.onSuccess(result) and >> Callback.onFailure(cause) because it is used everywhere. >>> >>>> 3 ) Platform implementation docs. A document with the code >>>> examples/comparisons and notes where they may diverge from >> each other. >>>> For instance in Android Callback is passed instances of the >> resource a >>>> pipe represents, but in iOS and Javascript the callback is >> passed a >>>> map of values. I didn't explicitly define this behavior in >> the spec. >>> Isn't having the parallel usage examples enough? (kinda like we >> did on >>> the paging spec) >> Pretty much, I was just wondering if people were interested in >> having a >> Map behavior as a standard, leaving it to the implementation, or >> doing >> something else (like returning Headers and Body information) >> >> >> >> I agree, coming from java, the map thing _is_ weird :) but that's >> what a lot of folks do, in iOS land. >> I guess... we could spec this - but also keeping it abstract, not >> really sure, to be honest >> >> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 <mailto:aerogear-dev@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

On Mon, Apr 22, 2013 at 6:37 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 04/22/2013 12:45 AM, Douglas Campos wrote: > On Fri, Apr 19, 2013 at 08:04:12AM -0400, Summers Pittman wrote: >> So I've gotten a draft of the Pipe document up. >> >> https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... >> >> Some things I would like to call out and discuss include >> >> 1 ) Pipe implementations should be thread safe. Specifically calls to >> read, remove, and save should not change the internal state of a Pipe >> object. > +1 > >> 2 ) Pipeline.get is not guaranteed to always return the same instance >> of a Pipe. This is something that came up with Android. Loaders are >> 1:1 on the Activity or Fragment which references the Loader. >> Therefore if a Pipe is reused between multiple Activities each one is >> proxied in a different Loader. > Why should we spec this? People counting on getting the same instance on > year 2013... I just feel like it is one of those things that if we don't say up front people may rely on it. > >> 3 ) A Pipe may proxy or delegate to a handler and this handler can be >> exposed as a property. This is an Androidism as well. I think it can >> probably be dropped from the spec but I wanted to see what other >> people thought about it. > +1 on dropping, this just adds complexity, and complex specs == boring > read Will do. >> Some things which we may need to flesh out to make the spec more >> complete are >> >> 1 ) Authorization and Authentication. This is probably another >> document > We can probably just spec the Authentication/Authorization SPIs (very > thin API surface) So a separate doc then? > >> 2 ) A callback spec/definition. I am not sure whether this is a >> separate document or not. Either way it should be short and sweet. > Wdym? Could you elaborate more? We need to put down in writing Callback.onSuccess(result) and Callback.onFailure(cause) because it is used everywhere. > >> 3 ) Platform implementation docs. A document with the code >> examples/comparisons and notes where they may diverge from each other. >> For instance in Android Callback is passed instances of the resource a >> pipe represents, but in iOS and Javascript the callback is passed a >> map of values. I didn't explicitly define this behavior in the spec. > Isn't having the parallel usage examples enough? (kinda like we did on > the paging spec) Pretty much, I was just wondering if people were interested in having a Map behavior as a standard, leaving it to the implementation, or doing something else (like returning Headers and Body information) I agree, coming from java, the map thing _is_ weird :) but that's what a lot of folks do, in iOS land. I guess... we could spec this - but also keeping it abstract, not really sure, to be honest

> _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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

So I've gotten a draft of the Pipe document up. https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... Some things I would like to call out and discuss include 1 ) Pipe implementations should be thread safe. Specifically calls to read, remove, and save should not change the internal state of a Pipe object.

2 ) Pipeline.get is not guaranteed to always return the same instance of a Pipe. This is something that came up with Android. Loaders are 1:1 on the Activity or Fragment which references the Loader. Therefore if a Pipe is reused between multiple Activities each one is proxied in a different Loader.

3 ) A Pipe may proxy or delegate to a handler and this handler can be exposed as a property. This is an Androidism as well. I think it can probably be dropped from the spec but I wanted to see what other people thought about it.

Some things which we may need to flesh out to make the spec more complete are 1 ) Authorization and Authentication. This is probably another document

2 ) A callback spec/definition. I am not sure whether this is a separate document or not. Either way it should be short and sweet.

3 ) Platform implementation docs. A document with the code examples/comparisons and notes where they may diverge from each other. For instance in Android Callback is passed instances of the resource a pipe represents, but in iOS and Javascript the callback is passed a map of values. I didn't explicitly define this behavior in the spec.

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