Hi Jukka,
Thanks for the comments. I generally share you concerns about the goals
and terms being to vague. As it stands this is only a dump from what we
gathered at our F22 and it is to be discussed and further clarified.
I plan to span off separate discussions thread about the issues you
raised and probably about others sometimes next week. This should help
us pushing this forward.
Michael
On 16.2.12 15:39, Jukka Zitting wrote:
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
