Hello again, I'd like to reach to a conclusion for this feature and we currently have the following options:
1. use RegEx for these filters, as proposed by Stefan Seifert - we're already using RegEx for Sling Mapping 2. use a limited glob pattern matching, allowing just '**', '*', as proposed by Carsten 3. use the full glob pattern matching syntax defined at [4] 4. support both regex and glob, but then force consumers to use the 'glob:' / 'regex:' prefixes for their patterns I'm still not a big supporter of RegEx usage in this case, due to their complexity and potential to match more changes than needed due to simple mistakes in the syntax: compare '/apps/**/*.html' with '^\/apps\/[a-zA-Z0-9:_\-\.]*\/?[a-zA-Z0-9:_\-]+\.html$'. However if we really need to support RegEx I'd prefer option 4, where at least consumers can write simpler matching patterns if needed. Thanks, Radu On Mon, 18 Jul 2016 at 15:37 Radu Cotescu <r...@apache.org> wrote: > 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 >> >>
