Hi,
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 Thoughts?
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? regards, david
