jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [j3] Repository MicroKernel API draft
Date Mon, 20 Jun 2011 08:57:28 GMT
On Sun, Jun 19, 2011 at 3:15 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Fri, Jun 17, 2011 at 6:37 PM, Stefan Guggisberg
> <stefan.guggisberg@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.

correct.

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

typically yes, but not necessarily.

> Are we expecting
> such code to have to parse and generate JSON strings whenever it wants
> to access the underlying content?

yes, and i don't think that it's a problem.


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

agreed. since the audience of the MicroKernel API is pretty small
programmer-friendliness has admittedly not been a top priority ;)

OTOH portability, remotability, stateless nature and compactness
have been. having those goals in mind, JSON is IMO a perfect fit.

cheers
stefan

>
> BR,
>
> Jukka Zitting
>

Mime
View raw message