Hi,
Last week has been pretty busy with the Oak Hackathon on Tuesday
followed by the .adaptTo 2012 conference (http://adaptto.mixxt.de/)
Wednesday to Friday in Berlin.
* The Hackathon
(http://wiki.apache.org/jackrabbit/Oak%20Hackathon%20September%202012)
was quite a success even though not too much hacking has actually taken
place. Half of the roughly 10 attendees where new to the project so we
decided to turn this more into an intro session. Jukka and Michael gave
a preview on their Oak presentation for .adaptTo 2012
(http://goo.gl/7fikE) and Jukka went through some coding examples
showing how to write a custom commit hook for Oak. The code examples
will become parts of the NodeState model documentation. See
https://github.com/apache/jackrabbit-oak/blob/trunk/doc/nodestate.md.
We briefly discussed about repeating this kind of event and I think we
agreed that this would be a good thing. I will follow up in a separate
thread to sort out the details regarding time frame and location.
* Jukka's and Michael's presentation "Jackrabbit Oak - the next
generation content repository" (http://goo.gl/7fikE) generated quite
some interest at .adaptTo 2012. Most questions revolved around issues
related to backward compatibility, better scalability in cluster
deployments and the impact of snapshot isolation.
* The documentation on the NodeState has further evolved. Most notably
there is a new section on how to build new node states using the node
state builder. See
https://github.com/apache/jackrabbit-oak/blob/trunk/doc/nodestate.md.
(Note that the Github mirror lags a bit behind. So if the relevant
content is not their yet use this svn link:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/doc/nodestate.md?view=markup)
* Last week's testing resulted in a flurry of filed issues on the
QueryEngine parsing and interpretation of results. We uncovered some
inconsistencies on node type handling (OAK-325), full text condition
parsing(OAK-), like on path constraints (OAK-347) and a bunch of JCR
functions that are not supported yet in Oak (excerpt, defer, similar, eq).
As work on the query engine itself stabilises there is a bit of advance
happening on the custom query index side: Lucene is chugging along
nicely (OAK-340, OAK-334), and more interestingly we have a Solr
integration up for review at OAK-307, take a look if interested!
A gentle reminder, the main JIRA issue that tracks query related
problems and inconsistencies compared to jackrabbit is OAK-237.
* Tudor Rogoz contributed an initial version of a performance test suite
for the Microkernel which can be used for benchmarking the various
implementations we have. We envision to use this also for scalability
testing of cluster deployments further down the line. See OAK-335 for
the respective JIRA issue and
http://svn.apache.org/viewvc?rev=1392315&view=rev for the contributions
itself.
* With the resolution of OAK-197 there are some minor changes in the Oak
API: the ConflictHandler argument was removed from the Root.commit() and
Root.rebase() methods. We figured that these parameters unnecessarily
complicate the client API and break encapsulation and thus decided to
move the conflict handling logic to a plugin instead of exposing it this
way through the API.
* In revision 1392352
(http://svn.apache.org/viewvc?rev=1392352&view=rev) Marcel moved the
repository setup code from ContentRepositoryImpl and ContentSessionImpl
to its own plugin InitialContent. The refactored OSGi related classes
allow to hook this directly into the life cycle of the Microkernel.
* On the debating side there was a discussion on whether and how we want
to support virtual content in Oak
(http://markmail.org/message/3fpssbdv6srabwx6). Not much progress so far
but I expect this to be a topic which will pop up rather sooner again
than later.
A further - rather lengthy debate - was on custom index configuration
(http://markmail.org/message/bdgi77dd6wy2hkbp). As far as I could follow
it was mainly about whether to store the index (configurations)
centrally or locally with the content. While we currently don't have an
implementation for the non centralised case, I think we can expect some
experimental ones soon. This will probably allow us to make a better
informed decision on which way(s) to go.
Also there was a discussion to go beyond mere path base access in the
Microkernel (http://markmail.org/message/vwq22osa7q2anm33). The
motivations for bringing this up was that path based access doesn't seem
to scale too well in the MongoDB based implementation.
Finally a rather recent discussion is concerned about the destiny of Oak
(http://markmail.org/message/ga4mn2x2xqsvzwg6) and is all about whether
Oak should graduate into its own project or become Jackrabbit 3.0
replacing the current Jackrabbit trunk. While the discussion is still
ongoing most of the opinions raised so far seem to be in favour of the
2nd option.
Thanks to Alex for providing the query/indexing section of this write up.
cheers,
Michael
|