[aerogear-dev] Pipe spec

[Kris Borchers]

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.

Thanks,
Kris

On Apr 23, 2013, at 4:03 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Mon, Apr 22, 2013 at 6:37 PM, Summers Pittman <supittma at 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/aerogear-client-pipe/index.markdown
> >>
> >> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130423/801abcbe/attachment-0001.html