For someone who preaches "no dependencies on ordering!", synchronous
events are just ordering in sheep's clothing. :-P
-> richard
Peter Kriens wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
