jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Observation design (Was: svn commit: r1351414 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak: api/ChangeSet.java api/ContentSession.java core/ContentSessionImpl.java)
Date Wed, 20 Jun 2012 13:40:32 GMT


On 20.6.12 13:16, Jukka Zitting wrote:
> Hi,
>
> On Wed, Jun 20, 2012 at 1:26 PM, Michael Dürig<mduerig@apache.org>  wrote:
>> Yes but... with and without such a lease mechanism my approach is more
>> general and doesn't hurt anything: if older revisions are available my
>> approach generates a more fine grained set of events. If older revisions are
>> not available any more it just gracefully degenerated to your approach. If
>> in the extreme only two revisions (last observed and latest) are available
>> it is the same as your approach.
>
> OK, I'm fine with that. This means basically that we don't make
> guarantees about things like user data, etc. Should we just drop them
> entirely instead of having a vague "they might be there but don't rely
> on it" contract?

Leaving userdata out works for me. Not sure what the "spec police" will 
say though ;-)

I'd however like to keep a container for the events (i.e. trees before 
and after). Currently this is called ChangeSet but I'm fine with a 
different name. This is a place where related meta data lives: 
timestamp, originating cluster node id, whether this change originated 
from a sync or not, session id which generated this change, ... I can't 
say which of these and in what form but I'm pretty sure we are going to 
need a way to convey additional information to the client.

Michael

>
> BR,
>
> Jukka Zitting

Mime
View raw message