10:17 a.m.
On 18 Mar 2015, at 13:04, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>>:
On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote:
>
> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>>:
>
> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote:
>>
>>
>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>>:
>>
>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote:
>> sequentializing them arbitrarily just makes it not async anymore
>> the event firing thread won't wait for event delivery so it is still async
>>
>> well doesn't change the fact you break original async need/wish doing it.
> break what?
>
> don't wait behavior, own thread model by call which is what async means most of
the time
Well, the thread firing an event won't wait for the observers to complete so I cannot
see how it breaks your "original async need/wish". Or do you associate
"async" with splitting the work into as many parallel threads as possible? If so
then we have a mismatch in terminology.
FWIW this is what I would interpret an async observer model to be, yes. An async fire,
perhaps not. However I think it’s unnecessarily limiting to design the ability to do this
out of the spec, especially for an edge case such as asynchronous ordered observers.
If you are writing an async observer, you clearly need to make it’s functionality
idempotent, or expect things to go weird.
Ordered observers are something I’m still not overly happy about ;-)
well about terminology maybe but I more think about expected behavior as a user. Think we
now both get what we each of us put behind async and question is what's the most
common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not
the same thing at all.
>
>>
>>
>> (+ think to the case you dont really have priorities you are just breaking the
whole concept).
>> If you do not have priorities (or they are the same) then it is most likely fine
to notify the observers in parallel. If you however do have priorities then it makes sense
IMO to take them into account. Doing otherwise just complicates the entire concept by
adding an artificial constraint.
>>
>>
>> point is you are introducing a model concept which is not aligned on the common
model + doesn't even match correctly the async needs (what about onFailure() and
onTimeout() which are mandatory when doing async)
> what common model?
>>
>
> callbacks one which is the only one making async usable and prod compatible
Which part is not aligned? In the current proposal you get a callback when all observers
complete or an exception occurs. In what order the observers are called does not change
anything about that.
you don't control the timeout and exception from the callback. I mean in the observer
chain which is what is needed most of the time (it helps me to think to it with a
javascript example but maybe my personal feeling).
>> I tend to join Mark saying we should just do the minimum instead of wanting to do
to much and providing something highly broken we'll need to fix in next version with
more broken patterns. What's the need is the real question, not what would be cool to
implement.
>>
>> Don't forget an async spec smells more and more strong with real async
semantic and solutions so I guess the less we put in CDI now better it is.
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.