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
