2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)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>:
>
> 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>:
>
>>
>> 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.
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.
>
>
>