On Sun, Jun 19, 2011 at 3:15 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote:
> 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.
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
>
