Hi, I'm also a supporter of the glob pattern matching, since those filters are easier to write than RegEx [3] (and not just because we'd have to escape every '/'). We could try to support the full syntax described at [4], though, if we need more flexibility.
Regards, Radu [3] - https://xkcd.com/1171/ [4] - https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher(java.lang.String ) On Sat, 16 Jul 2016 at 17:56 Carsten Ziegeler <cziege...@apache.org> wrote: > 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 > cziege...@apache.org > >
