hi bertrand
>On Fri, Oct 25, 2013 at 8:53 AM, Angela Schreiber <anch...@adobe.com>
>wrote:
>> ...the biggest challenge i see in terms of backwards compatibility is
>> that the diff-mechanism in OAK doesn't allow a 1:1 translation
>> to JCR events as they used to be generated in jackrabbit-core...
>
>The OSGi events that Sling rebroadcasts are less granular than JCR
>events, so this might not be a problem for that case.
do you know it or are you guessing?
carsten writes:
"1. Compacts observation events into node added, node changed, and
node removed events [...]"
and an example where oak differs from jackrabbit-core:
on the diff you will neither get nodeAdded nor nodeRemoved if a
referenceable node is being removed and a new one is being added
with the same name. the only thing that changes is the jcr:uuid property
and you can't find out if this was due to a change of the property
(which was possible on the OAK API) or if the parent node has been removed
and re-added. the reason is that the diff doesn't know about referenceable
nodes
and thus ignores that from a JCR point of view these 2 nodes are not
the same.
another example:
there exists Node#setPrimaryType which will modify the jcr:primaryType
property. in the diff you can't find out if someone called
Node#setPrimaryType
or if someone call Node#remove followed by Node#addNode(previousName,
newPrimaryType).
in jackrabbit the add/remove scenario always was add + remove because
every
single node had a unique identifier... thus the 2 use cases where
easy to distinguish.
so, to my knowledge it's currently not possible to reliably generate
the exact same result for the OSGI events when running on OAK compared
to Jackrabbit (irrespective on whether you do it on the OAK level or
reading JCR events).
and what i am asking for is that we stop speculating whether it might
be a problem or not but finally get hard facts.
kind regards
angela
>
>If at some point we can say "low-level JCR events behave slightly
>differently between Oak and Jackrabbit, but the higher-level OSGi
>events that Sling provides are the same" that might be a realistic
>compromise.
>
>> ...we keep getting mixed signals
>> ("be fully compatible" vs "just make it scalable and fast") and need
>> get a more reliable feedback to in...
>
>So maybe being fully compatible (*) at the Sling level, and scalable
>and fast at the JCR level, is a good way forward.
>
>-Bertrand
>
>(*) might require some Sling client code to indicate more precisely
>which events it wants to listen to, but that's a reasonable price to
>pay IMO
