Re: [aerogear-dev] Pipe spec
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)