I am not sure I fully agree. Though I do see the problems with
synchronous events I also see advantages. It is true that the
synchronous nature of external devices is not very relevant, but most
services are software based. In OSGi, services are often used as
dependency anchors. Treating these async, will make this less
reliable ... I think.
Interestingly, bundle events are async but a couple of years ago we
added synchronous bundle events because many people felt they were
needed. It is easy to blame what you know and idealize what you have
not ...
So I think it is not a black and white issue. Programmers should be
careful to use the synchronous events but I am not ready to declare
them all evil. It is easy to go from sync to async, vice versa is
impossible.
Kind regards,
Peter Kriens
On 13 feb 2009, at 21:51, Richard S. Hall wrote:
I agree this is the theory, but it (i.e., services blowing up when
you use them) is not something that can really be prevented.
Services can go away at any time, so you never know when you use one
if it will blow up, you have to treat them like remote references
and assume they always could blow up.
Further, just because the OSGi framework holds onto a registration/
reference/object does not give you any guarantees that you can do
anything graceful in a synchronous event. If the object is the front-
end to a bluetooth device and the devices was powered off or went
out of range, no amount of synchronicity by the framework is going
to stop the service object from blowing up when you touch it.
Of course, people like the warm and fuzzy feeling that the framework
is providing them some guarantees. :-)
-> richard
Todor Boev wrote:
The synchronous event delivery is an attempt to make service
unregistration more graceful. This is the only way to provide an
'unregistering' event as opposed to 'unregistered'. E.g. when you
receive the event the service is still up and you can gracefully
stop using it. So before the call to "unregister()" returns there
is room for some final calls to your service as users get notified
and shut down.
If the service events were asynchronous the users of the service
would potentially blow up with an exception while attempting to use
it and only than receive an "unregistered" event. So the whole
point of the event goes down the drain - you want to know it's
going to go down before it does so you can avoid crashing with
exceptions right? At the same time the caller of "unregister()"
wants to know that when his call returns the service is no longer
used by no one and he can proceed to release the resources of the
service with no fear that someone will call in and mess something up.
Put all of these considerations together and it seems to me only a
synchronous unregistration event will work. And since the
unregistration must be synchronous it will be evil to make the
registration asynchronous don't you think? :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
