On 24.10.2013, at 16:55, Justin Edelson <[email protected]> wrote:
> Given that there's already an expression syntax defined in the > EventAdmin specification, wouldn't it make more sense for Oak to just > use OSGi Events? That's the only way I personally could forsee us > being in a position to deprecate/remote the JCR Observation/OSGi > EventAdmin bridge which we have in Sling today. I don't think Oak wants to be tied to OSGi, but the expression syntax could maybe reused. > FWIW, I'm not sure it's a straight comparison between the bridge we > have in Sling and the CQ Workflow engine. The CQ Workflow engine > *could* be implemented by registering specific OSGi event listeners > (one per launcher). It just isn't (or so your email implies :). Not really, because it has to make the decision on matching events *itself*. Because of that, it is natural to only have one central listener (it quickly forks off into separate jobs once a match for a certain entry has been found). What I am asking for is that Oak provides those options (match on property values etc.) directly and it can handled as early as possible, without Oak having to call an event listener in the first place (and start a new thread etc.) in case there is no match. Cheers, Alex
