jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [Jackrabbit Wiki] Update of "Goals and non goals for Jackrabbit 3" by MichaelDürig
Date Thu, 16 Feb 2012 16:46:13 GMT

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<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.
>
> BR,
>
> Jukka Zitting

Mime
View raw message