Hi, A agree with Marcel, the current Jackrabbit SPI it too high level.
> it must be impossible to create inconsistent data using the micro-kernel API > - tree and referential integrity awareness +1. No more consistency check / fix. No more inconsistent index if the property-value-index is also part of the micro-kernel. > - long running transaction support I think 'large' transaction support is important, but it doesn't need to be very fast. I would avoid creating temporary files (persisting the cache). Instead, changes could be written to storage, but not committed. A few ideas (but I'm not convinced all of them are good ideas): - In memory, each node points to its (main) parent. If a node is in memory, then its parent is also. - Nodes are immutable (in memory, and on disk). Each change (or at least commit) will replace all parent nodes including the root node. - No change merging. Instead, use MVCC (when reading) and 'node level write locking'. As far as I know this is like most MVCC databases work. Actually we could use 'property level write locking'. - Support multiple persistence backends (database, file system,...). - Support two phase commit and distributed transaction at a very low level, so that it's very easy to distribute data to many storage backends. - Move operations are copy+delete internally (maybe reordering a node in the list of child nodes is also a move). - Subtrees that didn't change for a longer time are eventually persisted as one blob in the data store in a form that is compact and fast to read Regards, Thomas
