<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/23/2013 05:03 AM, Matthias
Wessendorf wrote:<br>
</div>
<blockquote
cite="mid:CAAg5f2QES69GP94MeTaji920GwbVaAGd7okQ8asa54ao9torAQ@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true" 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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
I'm leaning toward leaving this as an implementation detail. <br>
<blockquote
cite="mid:CAAg5f2QES69GP94MeTaji920GwbVaAGd7okQ8asa54ao9torAQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</body>
</html>