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 15:01:37 GMT


On 20.6.12 15:44, Jukka Zitting wrote:
> Hi,
>
> On Wed, Jun 20, 2012 at 3:40 PM, Michael Dürig<mduerig@apache.org>  wrote:
>> Leaving userdata out works for me. Not sure what the "spec police" will say
>> though ;-)
>
> To pass the TCK without user data we'll need to set the observation
> supported descriptor to false. I'm OK with that as long as we still
> implement most of the JCR observation interfaces and document the less
> strict observation contract that we are supporting.
>
> If needed, we could propose to JSR 333 to relax the specified
> observation contract or at to introduce more fine-grained descriptors
> that allow an implementation like ours to declare at least some
> observation functionality as supported.

Spec. wise this is fine. Implementation wise I'm not convinced. Who 
cares about the descriptors anyway ;-) Not even the TCK does... However 
let's leave it at this for the time being. I think this feature is 
rarely used if at all and we should concentrate on the important stuff 
first.

>
>> 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.
>
> Would it be better to pass these things as arguments to a callback
> method instead of as a container object returned by a blocking method
> call? I find the blocking method a bit troublesome as it requires a
> separate thread for each listener.

The client controls blocking through the parameter it passes. So this 
shouldn't be a big issue.

>
> As another design alternative, the Validator mechanism we have in
> .core.spi.state suggests a very similar Observer pattern (essentially
> just a Validator without the option of throwing
> CommitFailedExceptions) that could be used by a plugin to directly
> generate JCR-level observation events without having to go through the
> Tree abstraction in the Oak API. That would allow us to directly
> leverage the existing diffing tools and other machinery for
> NodeStates.

Sounds like an interesting idea. I'll try to come up with something 
along these lines.

Michael

>
> BR,
>
> Jukka Zitting

Mime
View raw message