hi jukka, good work. very nice draft! i was working on a similar idea of a new persistence model which went a bit further in some detailes and was much alike how subversion stores it's content [0]. i see 2 additional fundamental paradigms that a persistence layer should be based on: 1. copies must be very cheep (and just recorded as reference) 2. multiple (or all) workspaces must be able to live on the same 'persistence tree'
the first point basically describes a 'copy be reference'. this allows very fast implementations of copy, checkin, restore, etc. the second paradigm allows very fast inter-workspace operations, like clone, copy, etc. regards, toby [0] http://subversion.tigris.org/design.html#server.fs.struct On 4/1/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi, Based on some idle thinking I've written up a proposed model for next gneration persistence in Jackrabbit. Instead of trying to explain the whole idea in an email I've written a web page (with diagrams!) to describe the model in more detail. You can find the model description at http://jackrabbit.apache.org/dev/ngp.html (it's not linked in the menu). To summarize, the model I'm proposing brings a heavily abstracted persistence layer up as the central focus point of the entire repository architecture. The persistence model I'm proposing has implications all the way to things like clustering implementation, node type management, and session handling. In fact it would revolutionarize almost all parts of Jackrabbit core. ;-) On the other hand, instead of seeing the proposed model as a revolution, it could be seen simply as a way to raise the prominence of the ChangeLog class over the ItemState model. Currently ItemStates are the central concept in Jackrabbit and the ChangeLog class is just a way to group together a set of ItemState changes. In the model I'm proposing the ChangeLog, or a revision, would instead become the central concept that governs not only read and write operations but also things like transactions and observation to a much greater degree than it does today. There are a number of open issues with the proposal, especially how to make it perform well and not use too much disk space, but I feel that the model is interesting enough for serious consideration and perhaps even early prototyping. I'm especially interested in hearing your thoughts on how feasible you think such a model would be and what potential pitfalls I may have missed. Any other comments and ideas are also welcome. BR, Jukka Zitting
-- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
