jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [j3] Repository MicroKernel API draft
Date Mon, 20 Jun 2011 10:53:46 GMT
> 2) The complexity of the API: this is a *a lot* simpler than the SPI.

You are mixing things up here. The SPI interfaces cope with versioning, 
access rights, search, workspaces, name spaces, node types, import, 
locking and observation. All of which is not present in the micro 
kernel. That's where most of the additional complexity comes from.


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

public static void main(String[] args) {
     Jackrabbit3.create().execute(args[0]);
}

No more API changes. Ever!

Honestly, I think we better live with the changes, face them and manage 
them instead of hiding them behind a string based api with ad-hoc 
semantics.

Michael

>
>> 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,
>> revision);
>>
>> 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,
> revision);
>
> 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);
>
> Regards,
> Thomas
>

Mime
View raw message