jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [Jackrabbit Wiki] Update of "Goals and non goals for Jackrabbit 3" by MichaelDürig
Date Thu, 16 Feb 2012 14:39:14 GMT

On Thu, Feb 16, 2012 at 12:22 PM, Apache Wiki <wikidiffs@apache.org> 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.


Jukka Zitting

View raw message