On 20.6.12 15:44, Jukka Zitting wrote:
Hi,
On Wed, Jun 20, 2012 at 3:40 PM, Michael Dürig<[email protected]> 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
