jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Nuclear Fission, Splitting the core: The SPI Effect [was: Improving the accessibility of the Jackrabbit core]
Date Mon, 11 Sep 2006 08:36:00 GMT
Hi,

On 9/7/06, David Nuescheler <david.nuescheler@gmail.com> wrote:
> In my mind the introduction of the SPI would lead to a clean
> split of the Jackrabbit core architecture that allows for
> much better re-use and better transparency. Essentially
> the "core" could be reduced to the "server" which should
> siginifcantly reduce the complexity.

I very much agree with the benefits of the SPI approach, especially
for remoting and re-use.

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.

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. What would a
more deeply integrated spi2jackrabbit component look like, and how
would we implement it in the core?

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?

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message