ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn commit: r1335048 - in /ace/site/trunk/content/dev-doc/analysis: bundlerepository-analysis.mdtext index.mdtext
Date Mon, 07 May 2012 14:47:00 GMT
Author: marrs
Date: Mon May  7 14:47:00 2012
New Revision: 1335048

URL: http://svn.apache.org/viewvc?rev=1335048&view=rev
Log:
Initial conversion of the bundle repository analysis.

Added:
    ace/site/trunk/content/dev-doc/analysis/bundlerepository-analysis.mdtext
Modified:
    ace/site/trunk/content/dev-doc/analysis/index.mdtext

Added: ace/site/trunk/content/dev-doc/analysis/bundlerepository-analysis.mdtext
URL: http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/analysis/bundlerepository-analysis.mdtext?rev=1335048&view=auto
==============================================================================
--- ace/site/trunk/content/dev-doc/analysis/bundlerepository-analysis.mdtext (added)
+++ ace/site/trunk/content/dev-doc/analysis/bundlerepository-analysis.mdtext Mon May  7 14:47:00
2012
@@ -0,0 +1,45 @@
+Title: Bundle Repository Analysis
+
+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:
+
+1. use an existing solution;
+2. 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.
\ No newline at end of file

Modified: ace/site/trunk/content/dev-doc/analysis/index.mdtext
URL: http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/analysis/index.mdtext?rev=1335048&r1=1335047&r2=1335048&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/analysis/index.mdtext (original)
+++ ace/site/trunk/content/dev-doc/analysis/index.mdtext Mon May  7 14:47:00 2012
@@ -2,4 +2,6 @@ Title: Analysis
 
 * [Security Analysis](security-analysis.html)
 * [Template Mechanism](template-mechanism.html)
-* [Audit Log Analysis](auditlog-analysis.html)
\ No newline at end of file
+* [Audit Log Analysis](auditlog-analysis.html)
+* [Bundle Repository Analysis](bundlerepository-analysis.html)
+



Mime
View raw message