[aerogear-dev] Pipe spec

[Summers Pittman]

On 04/23/2013 05:03 AM, Matthias Wessendorf wrote:
>
>
>
> On Mon, Apr 22, 2013 at 6:37 PM, Summers Pittman <supittma at redhat.com 
> <mailto: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
>
I'm leaning toward leaving this as an implementation detail.
>
>     >
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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/61ef445f/attachment-0001.html