Hi,
On Fri, Jun 17, 2011 at 6:37 PM, Stefan Guggisberg
<stefan.guggisb...@gmail.com> wrote:
> one of the design goals of the MicroKernel API was "easy portablilty".
> typically it would be used in-proc by some higher level code, comparable
> to the current SPI.
To me it seems like the JSON parts of the API would be better suited
for a higher-level integration layer.
The problem here is that since the MicroKernel is an intentionally
low-level API, we'll need a lot of higher level code to implement
features like versioning and search. My assumption is that these
components would still reside in the same JVM as the MicroKernel and
thus access it through the defined Java interface. Are we expecting
such code to have to parse and generate JSON strings whenever it wants
to access the underlying content?
Consider, for example, a simple task of updating a counter. The JCR
API for that is something like this:
Property count = session.getProperty("/counter/count");
count.setValue(count.getLong() + 1);
session.save();
The equivalent MicroKernel code, as far as I understand the API, would
be something like this:
String revision = microkernel.getHeadRevision();
String counter = microkernel.getNodes("/counter", revision, 0, 0, 0);
JSONObject json = new JSONObject(counter);
long count = json.getLong("count") + 1;
revision = microkernel.commit("/counter", "^count:" + count, revision);
This doesn't strike me as a particularly programmer-friendly API.
BR,
Jukka Zitting
