jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [j3] Repository MicroKernel API draft
Date Mon, 20 Jun 2011 10:17:53 GMT

>To me it seems like the JSON parts of the API would be better suited
>for a higher-level integration layer.

What other API do you suggest, and why/how would it be better than JSON? A
few advantages of using JSON:

1) Loose coupling: the MicroKernel doesn't have to know all the details
about the higher level (data types,...).

2) The complexity of the API: this is a *a lot* simpler than the SPI.

3) No API change required if we add features. This is similar to using SQL
as the API (as in ODBC, JDBC): the API is simple ("execute(String sql)"),
so both clients and servers can evolve without having to change the API a
lot if there is a new feature. Actually, JDBC is worse because the data
types are part of the API.

>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.

Versioning: In the current implementation, versioned content is like
regular content, except for a different path and additional properties. I
would probably use a similar mechanism for Jackrabbit 3. I don't see how
using a different API would help here.

Search: We didn't start implementing search yet, and we didn't discuss
this yet. I think it would be too early to define an API at that point, or
even the search architecture. A few options are:

- Use Lucene as we do now.
- Use some other indexing mechanism; don't store data in the MicroKernel.
- Use some other indexing mechanism; store data in the MicroKernel.
- The MicroKernel could provide low-level indexing features
  (to be defined).

>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,
>This doesn't strike me as a particularly programmer-friendly API.

It's actually quite programmer-friendly in that you can easily debug
(having everything as strings). I think this actually doesn't look too bad
(for a low-level, internal API). It's a bit simpler/different though:

String counter = microkernel.getNodes("/counter", revision);
revision = microkernel.commit("/counter", "^ \"count\":" + count,

If it turns out that "incrementing" is very important, we could also add a
new feature for it (without having to change the API):

microkernel.commit("/counter", "+= \"count\": 1", revision);


View raw message