Hi, On Thu, Feb 16, 2012 at 12:22 PM, Apache Wiki <[email protected]> wrote: > === Design principle === > Best effort: everything might be corrupt at any time: > * node types > * child node existence > * clients may not make '''any''' consistency assumptions
That's too vague, IMHO. A client needs to be able to make *some* assumptions about the consistency of the repository. For example, if I write something to the repository and nobody else modifies that content, it should be safe for me to assume that the content still exists (in a consistent state) when I next look for it. What happens when others modify the content is a different question, but even there we need to be able to give some deterministic guarantees about (eventual) consistency. Also, the word "corrupt" here sounds quite harsh. IMHO a corruption is always a big problem. Instead we may want to allow the repository to be at times "out of sync" or "temporarily inconsistent" as long as it'll eventually reach a more stable state. > * Pass TCK. But TCK might be adapted for invalid or edge cases. "Pass TCK" is a bit vague unless we specify which optional features we intend to support. Any changes to the TCK need to be based on a more accurate reading of the spec or (where we feel the spec is too strict) a proposal to JSR 333 to relax the requirements. > Scalability: We need more specific benchmarks for these. Good early guidelines though. > === Non goals === > [...] > * Consistency guarantees As discussed above, we IMHO definitely need consistency guarantees, the question is just how strict we want to make them. > * JCR lock == sync Can you elaborate? I'd either implement locking correctly or not implement it at all, not something in between that a client can't really rely on. BR, Jukka Zitting
