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
