I think we should keep it simple and model it based on existing use cases. So far, the only pattern matching which comes to my mind is matching based on the extension. Basically everything that is caching something requires this, like the jsp engine being interested in changes of *.jsp files etc. Apart from that listeners are usually interested in changes in a specific sub tree, but without any additional filtering.
Therefore I think the **, * matching similar to what we know from Ant or Maven or other tools should be enough. I wouldn't go with more powerful matching as the idea of the RCLs is that the filter matching is done by the underlying storage provider, e.g. Oak. This allows to delegate the heavy work to the storage and reduce the number of events send by the storage to Sling. Of course, if the storage can't filter itself, the Sling provider implementation can still do an additional filtering, but that might be rather expensive. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
