Hi, On Jan 14, 2008 1:43 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > 1) When using a full revision based storage it might be good to look > at the SVN implementation. In fact, for the performance it is > important to have the most-requested nodes and property versions > readily available without long parsing and merging algorithms.
My current plan is to store all versions as-is without any diffing or merging. I'm not yet sure about the storage implications of this and what sort of garbage collection algorithm we could use to reclaim unused disk space, but at lea accessst performance shouldn't be a concern. Note that unlike Subversion, NGP does not need to keep *all* previous revisions, only those that are currently being accessed or reserved for hot backup, point in time recovery, etc. JCR versioning should still be used if an end-user wants to keep old versions of content. > 2) What about SPI? How will the SPI interface and the NGP relate? Is a > rewritten Jackrabbit supposed to implement the SPI interface only (And > the client part will always be jcr2spi)? That would be nice, but there are actually some architectural mismatches between the current SPI and NGP that will probably make SPI a kind of a bottleneck for an NGP implementation. For example the handling of transient changes is quite different between SPI and NGP. > 3) Performance for remote storage: my experience showed that the best > performance with a fine-granular API like JCR can only be reached if > the user is able to query the entire set of elements he wants to > operate on in the beginning. [...] NGP sounds like something > that should incorporate such an improvement. By dropping the need for cache invalidation, NGP opens up quite a few options for caching content especially for remote readers. How to best handle indexing and queries with NGP is still an open issue (I'm leaning on storing Lucene segment files inside the repository), but it should be fairly straightforward to schedule all (reasonably sized) query result sets for remote caching. BR, Jukka Zitting
