On 2010-11-15 14.58, Niclas Hedhman wrote:
The ref is null, not a reference pointing to a null? I think this is
semantics that we might not have gotten right.
The reference relates to a specific service. If there is no specific
service that matches the qualifiers, then there's nothing that can be
injected.
There is no events going on, and I'm not sure it would be possible either.
In many cases it is only when a question is specifically asked that it can
be answered, e.g. "is a REST resource available? Well do GET and try!".
Well, when I worked on a GUI client many years ago with Jini backing
the available services on the network, it was much better to softly
disable features that became unavailable if a service disappeared,
than waiting for the user to execute the command and toss an error in
her face. We also had a simple indicator for "availability" based on
how many of the expected services were actually available, as a quick
reference.
We do that as well, but since we have a REST API backend with no asynch
events to client, we do a refresh when a panel is opened, including
asking for what services is available (this is just plain HATEOAS). If a
service is not available the button is greyed out or removed.´
This doesn't work if a panel is expected to be showing for a long time,
obviously. It can be mitigated by doing manual refreshes in such cases
though.
The problem is that in general it is not really possible to know when
availability changes, since it often relates to underlying services that
you cannot "monitor" (in non-Jini scenarios).
If you have a service hosted in Qi4j it can be "not active" but "available"
(i.e. you can start it up), and it can also be "active" but "not available",
so they are different. I'm just having a hard time seeing application/domain
code bothering with it. For SPI-type code it definitely is interesting, i.e.
"if service is active, passivate and activate it to restart it".
Ok, so the isActive() is actually "hasBeenActivated()" which
communicates the meaning better. Yes, I agree it barely makes sense in
API, but I am ok to keep it in ServiceReference. One far fetched
use-case I can imagine is that for a really slow starting service, one
might avoid calling it if it has not been activated, to avoid the
delay that it would incur... but OTOH how often does one have such a
choice?
From an application point of view, as I said, it is not very likely to
matter. If you want to call it, you call it, and that's that. isActive()
is more interesting from an admin point of view. But then it would be
enough to have SPI methods to check this.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
