On Monday 14 April 2008 17:23, Rickard Öberg wrote:
> Now I'm not too sure that's a good idea. The reason is that there are so
> many ways to invoke side-effects asynchronously (separate thread, put in
> JMS queue, send to JavaSpace, etc.), and they all have different
> semantics, that I don't think it's going to be so easy as to just mark a
> side-effect as @Asynchronous and that's it.
I think I disagree... ;o)
That it IS asynchronous is where the annotation comes in play. I mean, it
either IS or is not asynchronous. One could perhaps say that we instead have
a @Invocation taking an enum{ synchronous, asyncronous } as value, but
practically the same thing.
And IF it is asynchronous it is passed to some form of Asynchronizer, which
figures out "how" the asynchronization is supposed to happen. I think the
most straight forward way to do this would be to introduce such interface,
which is registered as service in modules in good old fashion.
Pushing it to side-effect implementor seems unnecessary, and possibly not
known either. I must say I wasn't able to follow your example...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
