On 01/14/2013 04:26 PM, Douglas Campos wrote:
On 14/01/2013, at 18:11, Summers Pittman <supittma(a)redhat.com>
wrote:
>> Hmm, so you only create the pipes at app initialization? Looks like I was missing
the android lifecycle.
> You can create one any time you like, but either a) each configuration
> would overwrite the old pipe in Pipeline or b) you would have obnoxious
> naming conventions.
I'm not following the naming conventions part, mind to elaborate?
I suppose it
just means you have to supply a name attribute to your
PipeConfig. What this means is that the name of the pipe stops being
the type of the pipe(which is our default) and starts being the role of
the pipe (which is a rather new concept).
> As a less contrived example, you may have a background process updating
> cached data and a foreground process querying data. For instance your
> background thread was downloading all of the cars but you only want to
> see five red cards. It makes sense for Pipeline.get("car") to be used
> by both threads.
And this is the place where we disagree - I would go straight to make sure that
background stuff have its own pipe instances ;)
I've been trying to keep the
pipe's methods threadsafe by minimizing
mutable and shared state. (PageContext is an exception, but WeakHashMap
explicitly uses the instance of the object for lookups and not the hash
code). While I do this there is (as far as my biased POV can see) no
good reason to have a single endpoint serviced by multiple RestAdapter
instances. I would like to keep doing things this way, but if it really
breaks the feel of a different language I can be flexible.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev