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: Building a Jackrabbit roadmap
Date Thu, 22 Mar 2007 16:05:08 GMT
Hi,

I would like to comment on a particular section of Jukka's excellent
summary of the major topics that we need to clarify on the development
roadmap. I would like to apologize for the delay.

> SPI
> ---
> The SPI effort has been ongoing for a while already, and it would be
> good to come up with a clear idea of how and when are we going to
> integrate it with the rest of Jackrabbit. The SPI model introduces a
> major architectural change, and I'm worried about the adverse effects
> that change may have if the integration with the rest of Jackrabbit is
> not properly managed.
> I'd most like to see the SPI being introduced as an evolutionary step
> to jackrabbit-core rather than using just parts of the current core to
> build a revolutionary new jackrabbit-spi-backend implementation.
I agree that in the longer term the SPI introduces an
additional layer that allows someone to implement the SPI
instead of JCR to pass the TCK, which probably is simpler
for any connector or adapter to a legacy repository
but also for someone who wants to implement a brand new
repository from scratch.

I think it is safe to say that we did not primarily focus on a
client/server model [1] when developing Jackrabbit v1.0,
which I think was a good decision at the time.

Nevertheless I think that a remoting beyond the current RMI
implementation more and more becomes a need and the SPI
offers very good direction there as well. Personally, I think
that the RMI implementation that goes through the SPI layer
should already be much faster than the "traditional" JCR RMI
remoting.

> The applicability of the SPI as an intemediate layer within a local
> repository implementation as opposed to a network remoting layer has
> also not yet been discussed in much detail. Before integrating the SPI
> with the rest of the project it would be good to review the design
> decisions both to verify that we're not missing anything and (even
> more importantly) to better educate the development community of the
> details of the SPI model.
Agreed.

I think that the natural step for a review of the applicability of the SPI for
Jackrabbit while conserving the current architecture was to introduce the
SPI over JCR layer that allows to for example use the SPI for remoting
on top of Jackrabbit and on top of other content repositories.

Possibly this will allow everybody to get more exposure and work with
the SPI to make sure that nothing was overlooked, before we drill
deeper in to the core. I very much agree that the Jackrabbit
development community needs to feel comfortable with the SPI before
we discuss an architectural change of that magnitude that I believe the
SPI would introduce.

Comparing timelines with JSR-283, it may well be that a completely
refactored Jackrabbit SPI implementation is not within reach for the final
release of JSR-283.
Nevertheless, I think that the current SPI over JCR implementation already
offers most of the benefits of the SPI, while only introducing a small
performance penalty. So I think we are in good shape for now.

Do you think that makes sense?

regards,
david

[1] http://jackrabbit.apache.org/doc/deploy.html#Model+3:+The+Repository+Server

Mime
View raw message