Hi Alex, 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.
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 :). The Observation/EventAdmin bridge, however, is intended to bridge these two eventing systems and so it pretty much has to listen for all events and then rebroadcast them (in slightly mutated form). Same thing is true if you are building an EventAdmin/JMS bridge or a JCR Observation/JMS bridge or anything like that. Justin On Thu, Oct 24, 2013 at 7:14 PM, Alexander Klimetschek <aklim...@adobe.com> wrote: > I don't think it's so theoretical: a generic observation listener such as the > jcr listener in sling, that handles all events all the time with no option to > reduce the scope in any way, seems like a barrier to scalability. > > The goal should be that any kind of observation should always be as specific > as possible (by path, properties, resource type etc.) and that should ideally > be handled on the oak level where it can be optimized the most. > > The problem basically was that the JCR observation listener API doesn't allow > much constraints, only path and node types. But not by property values. Or > other things. So "everyone" came up with his own generic dispatching > listener: sling with one that checks the resource type, the aforementioned > workflow launcher in Adobe CQ which allows any property values and other > constraints etc. > > There should be one in Oak, with a few common options (property values etc.) > that can be heavily optimized and optionally a custom function that runs on > the node in question and could handle more complex decisions whether to > handle the event or not (at your own risk regarding performance :)). > > Cheers, > Alex > > On 24.10.2013, at 00:04, Carsten Ziegeler <cziege...@apache.org> wrote: > >> As stated, so far the whole discussion is very theoretical - apart from the >> point that right now the jcr listener does a read for each and every >> changed node to get the resource type. This could definitely be improved >> with Oak as Oak is doing a content diff and therefore it should be possible >> to send this information down to the jcr listener. This would speed up >> things dramatically. >> But without concrete numbers and performance information, all of this >> sounds like premature optimization. Reinventing the wheel just slightly >> different without any way to proof whether it helps just doesn't sound >> right to me. >> We need to have a look at the whole system - it doesn't help if we talk >> about fixing one part of it for such scenarios while completely neglecting >> other parts. Therefore, (I know I repeat myself) I'm really looking forward >> to numbers showing the bottlenecks. >> >> Thanks >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org >
