Hi, On 9/7/06, David Nuescheler <[EMAIL PROTECTED]> 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/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
