Hello. I'm the author of a work-in-progress open-source-but-commercial computer game. One of the main design decisions has always been to support third party modifications out of the box. Current commercial computer games tend to handle this extremely badly, either by not providing APIs or by not providing any kind of versioning, dependency handling, security, etc. Given any modern computer game that has an active mod community, it's pretty much trivial to find a pair of mods that will essentially break each other when both applied to the same install as most rely on unsafe monkey patching and overriding of game data and code.
Clearly, if I want to support additions to the game, then the above is unacceptable and what is needed is a real plugin API and package system. Having looked at all of the available options, I've run across OSGi. I've picked through the OSGi specification, and it seems like it provides everything I could want, namely: A standard API to install and uninstall modification packages that can be given a nice in-game user interface. This includes the dynamic installing/uninstalling/activation/deactivation of modifications without having to restart the application. Sandboxing. I would want to run modifications with an empty set of permissions - no filesystem access, no thread creation, no reflection, no network access. The application itself would provide a limited set of privileged APIs. Taking this further, I suspect that the game "content" would itself be implemented as a set of bundles and treated as if they were ordinary untrusted modifications, running with no permissions whatsoever. Proper versioning and dependency handling. A modification specifies the versions of other modifications upon which it depends, and the downloading and installing is handled without the user having to rummage around on ad-laden game mod sites, manually installing and dealing with dependency hell. I've been developing the foundations of the game engine as a large set of very modular and strongly separated packages, all of which are released as open source (please see http://io7m.com) and are deployed to Maven Central once reaching some degree of API stability. I suppose I'm looking for insight as to whether the apparent complexity of OSGi is appropriate for my use case, and whether or not I would end up with something more complex if I built an ad-hoc specialized system. Additionally, I would want to keep my existing libraries OSGi-agnostic. That is, I want OSGi developers and non-OSGi developers to be able to use my libraries with equal ease. As I mentioned before, I've always tried to build packages that are strongly modular, and most of my published libraries already have the type of API/implementation separation that I observe in many existing OSGi packages. As I understand it, I could turn all of the libraries into bundles quite easily by changing the packaging type in each Maven module and adding the Felix BND plugin. This way, they would not actually depend on any part of OSGi, but would be usable both by OSGi developers and Java developers that are just using ordinary Maven packages alike. Does this sound correct/reasonable? Next, it's not clear to me how much of the application would actually be using the OSGi APIs. I have a rough idea in my head that the application itself would embed the most minimal OSGi implementation I've been able to find (Apache Felix) as opposed to running inside an OSGi container itself. It's not really clear to me how much of the application itself would be developed as bundles and how much of the code would be in the "host". I assume I'm not the first to think about a system like this, so how is it usually done? Finally: I typically develop libraries in a dependency-injection style, as seems to be a current best-practice. That is, an implementation never instantiates an implementation, but instead takes an interface argument on construction and keeps a strong reference to it forever. However, I do not use any form of automated dependency injection (nor would I particularly want to). Unless I've misunderstood, it seems that OSGi bundles tend to use a form of much more advanced and dynamic dependency injection by requesting access to services. This does, however, mean that the code then requires an OSGi implementation to actually work (which would conflict with my requirement of not forcing clients of my libraries to use OSGi). Is there a common way to engineer libraries such that they can use if available but not actually require OSGi services to work? Apologies for the length. Any insight is appreciated! Regards, Mark
pgpDb4fVnJBuA.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
