[aerogear-dev] Pipe spec

Matthias Wessendorf matzew at apache.org
Tue Apr 23 05:03:29 EDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130423/cbc28e1e/attachment.html 


More information about the aerogear-dev mailing list