jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: Nuclear Fission, Splitting the core: The SPI Effect [was: Improving the accessibility of the Jackrabbit core]
Date Wed, 13 Sep 2006 09:57:10 GMT

> However, I'm a bit concerned about the revolutionary approach of the
> SPI effort. Rather than refactoring the Jackrabbit core to better
> separate the session-local parts, the SPI comes up with a brand new
> interface contract. This is probably the best thing to do given the
> SPI goals, but it does leave the big question of how and when are we
> going to integrate it with Jackrabbit core unanswered.

I think you are right. Just to be clear, I do not look at the
architecture suggested or hinted by the SPI to be implemented
in a the very near future in a "clean" way.

My original intention of this thread really was to stimulate some
discussions around a possible "Jackrabbit 2.x" architecture.

> As of now the easiest way I see to integrate the SPI effort with the
> Jackrabbit core is through a generic spi2jcr adapter, but that doesn't
> really affect the core design or increase code re-use.

I agree.

As a side note: I even see value for an spi2jcr adapter
beyond the "mid-term" goal of a better remoting for the current
Jackrabbit core. I think that a spi2jcr adaptor (in conjunction with the
jcr2spi-client and the protocol bindings of the SPI) could serve as a
general purpose remoting layer for any JCR compliant repository.

Generally, I think we could also look at a phased approach, that
allows us to test, evolve and mature the components individually.

I think we could also do something like:
(Step1) Isolate the session-local parts into a "standalone" client (JCR2SPI)
(Step2) Build the SPI2JCR layer that exposes the current Jackrabbit
impl to the SPI
(Step3) Refactor the Jackrabbit core to "natively" implement the SPI


> What would a
> more deeply integrated spi2jackrabbit component look like, and how
> would we implement it in the core?
I am not sure how that would look like and I guess that this would be
subject to some investigations. It may well be that some portions
would benefit from being refactored to work efficiently.

> And on the other hand, how can the SPI effort better reuse the
> experience built into the session-local parts of Jackrabbit core?
> For example looking at the SessionImpl implementations from both jcr2spi
> and the core, I see quite a lot of duplicate functionality. How does
> the SPI make sure that the lessons learned developing the core are
> included in the new codebase?
I agree. I think the lessons learned should be transported through the
Jackrabbit Community and its experience with JCR and Jackrabbit
over the past years. Of course I would also prefer to re-use as much
existing and well tested code as possible. But personally I think
we should not make architectural sacrifices at this point.

I believe that the overlap and the redundance of the code between the
session-local parts and the core are rooted on the original compact
and intertwined design.

Do you think we would see the same overlap if we would basically
have a straight-up SPI implementation (on the "server"-side) more or
less from scratch and strictly separate the session-local parts?


View raw message