> On 31 Jul 2016, at 19:34, list+org.o...@io7m.com wrote: > > 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.
Be aware that this level of sandboxing will require you to enable Java 2 Security, which adds a performance overhead to any application. Since this is a game, you might not want to pay that penalty. Why do you need this… what’s the worst that could happen? > > 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? That’s one possibility, or you can use the bnd-maven-plugin that does not require you to change the packaging type. > > 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? It’s “normal" to deliver your whole application as bundles. What’s sauce for the goose is sauce for the gander. Of course you can write your application outside OSGi and only use OSGi for the “external plugins”, but why would you do this? Also you don’t really need to interact with the OSGi APIs, either in the core application or the plugins. You will need to touch OSGi APIs in management or “plumbing” code, e.g. where you need to download, install or update plugins… but aside from that, you should avoid them as much as possible. Use the Declarative Services annotations to write your code as Components with injected dependencies. > > 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? Yes. If you write Components with Declarative Services, they only depend on the annotation library at build time and will still be compatible with a non-OSGi runtime. You can hide dynamics from them by using the static policy for references. > > Apologies for the length. Any insight is appreciated! > > Regards, > Mark > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
