David Rauschenbach wrote:
Yeah, I think I hear what you're saying, and I understand that tight spot. I have to confess that I also use JCR2SPI as the primary client for SPI. But I have performance problems to solve, so that <n> JCR calls don't explode into <n>*6 SPI invocations, so I have to play all kinds of tricks now, to divine extra information from the client and/or server.
we should definitely improve that situation. so far we didn't invest too much time in performance analysis but first wanted to have an SPI stack that works correctly. I also think that it is now time to carefully analyze the message complexity for each JCR call and if needed change the SPI interfaces.
I like SPI because of its simplicity. But performance is problematic, and outside of my control right now, [...]
please let us know what issues you have with the SPI stack. feedback is always welcome and gives us an additional view on the SPI that we probably overlooked in the past.
you are also welcome to gain control ;) if you have ideas how to improve the SPI stack or have patches, please let us know and we will be happy to consider them.
[...] and I have caches and NodeTypeManagers in my SPIs, even though I am not supposed to.
at some point node type definitions were requested extensively. JCR-1030 should have improved that situation.
I also have my own PathElement comparators, to get SPI to work, so that 0 (unspecified) and 1 (default) indexes are considered equivalent, but that is another story...
Can you please describe in more detail why you had to do this? regards marcel
