"Strong" optionality
Richard Hall tells me Felix interprets optional imports as "strong", to use my earlier term. I believe there is enough latitude in the OSGi spec to permit this. Equinox takes the opposite interpretation and can discard optional imports of available packages in order to overcome uses constraints which would otherwise prevent resolution.
Regardless of that, I think that strong optionality is more likely to be what the user wants.
Without strong optionality, if the user provides a bundle which can satisfy some optional imports, they are not likely to be pleased if the resolver discards corresponding optional imports as the functions provided by the bundle will then be unavailable. Better to fail fast with diagnostics that allow the user to sort out the uses constraints.
Even worse, without strong optionality resolution may fail after a protracted attempt to discard combinations of optional imports in order to get a valid wiring. All the optional imports could be discarded before embarking upon a protracted search to ensure that the search is not in vain. Perhaps Equinox already does this, but I'm doubtful it as it could be criticised as optimising for the failure case.
8 comments:
Glyn,
Isn't the issue here that it shouldn't be down to implementations to decide how the resolution should happen?
I'm all for leaving some spec areas up to the implementations, but resolution is central to the usage model of OSGi. If users can't get predictable, easy-to-understand resolution across tens of bundles then something is amiss.
Rob
I agree that the spec should tie down whether or not optionality is strong as this makes a real difference to the user's model of OSGi.
But I'm not sure every detail of resolution can be tied down without implementation bias creeping into the spec.
This sheds a lot of light on things. Framework specific resolution behaviour makes life difficult for external resolvers like Nimble that are trying to anticipate the behaviour of the framework resolver; I have to admit that I’d previously interpreted Felix’s ‘Strong Optionality’ behaviour as a bug rather than an alternate interpretation of the spec.
One odd consequence of this approach is that installing a bundle X in Felix can make it impossible to resolve a bundle Y that would have resolved before X arrived. Equinox’s resolve everything if you resolve anything approach leads to similar behaviour.
I’ll probably write about all of this in more detail on the Nimble blog
By the way, I think that even if optional imports didn’t exist, versions and uses constraints alone would be enough to build an NP completeness proof.
It seems to me that the aim should be to find solutions that fit particular use cases rather than ones that are technically correct but unhelpful due to, e.g., unwired optional dependencies that are not so optional from the user’s point of view.
I think it would be useful if frameworks were able to delegate the resolution process to a third party resolver so that it could be guaranteed to have the same behaviour in any framework and configured to carry out the resolution in accordance with users’ policies rather than the framework’s best guess. The framework would still have to check the proposed solution of course.
Yeah. We've suffered from "dropped optionals" too which is where an optional dependency is provided late and the user doesn't realise they have to refresh to pick it up.
I'd be very interested in a proof avoiding the need for optional imports. Perhaps you could do it instead of the crossword over the weekend? ;-)
I agree pluggable resolvers might be useful. The interface would be an interesting exercise. I'm sure Tom and Richard must discuss this on a regular basis.
I've added some remarks at the end of the stackoverflow answer, one of which deals with building a version of the proof without optional imports.
The proof approach sounds plausible, although it's interesting that it now depends on transitivity of uses. Perhaps you could write it up for posterity when you have the time.
Post a Comment