The bundle repository stores actual bundles and other artifacts. It is kept external to be able to leverage existing repositories and better protect the intellectual property of our users.
Problem
The bundle repository is an external repository that stores the actual bundle data and other artifacts. We keep this data external to our system to better protect the intellectual property of our users. Having only the meta-data in our system ensures the bundles and artifacts themselves can remain on a separate, protected network, even when the provisioning server itself is used in a hosted or cloud environment.
Access to the bundle repository is URL based.
The use cases are:
- Get bundle, which returns the full bundle. This use case is mandatory, as this is the main goal for having a bundle repository.
- Get bundle meta-data, which returns only the meta-data. This one is nice to have, as it would help us on slow connections when we only want metadata.
- Get a list of (a subset of) all bundles in the repository. When provisioning, we already know what we want. When managing the shop we might have use for querying features and we should seriously look at OBR as an implementation. Also, as part of the Equinox provisioning effort, they are defining a similar model.
- Install/update bundle. Makes the repository editable from the outside.
- Delete bundle. Mentioned separately here because of the dangers of deleting bundles that might still be in use (the repository has no way of knowing what's in use).
Context
Whilst we will no doubt create our own bundle repository, it would be a big bonus if we could work with other bundle repositories. OBR comes to mind, but there might be others. Therefore it's important to create an implementation that maps easily onto (for example) an HTTP based repository.
Our requirement to have URL based access to bundles ensures we can do that.
Possible solutions
As mentioned before, we basically have two solutions:
- use an existing solution;
- creating our own.
Discussion
Most use cases can be done either way. If you look at the OSGi Alliance's RFC-112 for OBR, the only thing it does not support is manipulating a repository. You could argue that's because it is beyond the scope, and because currently, OBR can be implemented using any webserver (it's basically just a set of bundles and a single XML descriptor).
Conclusion
I think we should create our own implementation of OBR, extending it with editing capabilities, and perhaps subsetting it (at least initially, we might not want a whole requirements, capability and dependency mechanism in there right now, as that's something we deal with inside our provisioning system).
At the same time, adding these editing capabilities should not mean we cannot still generate static files that can be deployed on an external HTTP server. We do want to add an API for editing, but we don't want to make the whole repository depend on the capability to run code on that server, since we might want to do all maintenance on some client that simply uploads files to a server.