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