what about option 2 + 4 together (but only implementiong 'glob' currently)?
then it would be: - easy to detect if the user wishs to use a pattern instead of a fixed path by looking for a prefix (currently this is done by magically looking for special characters) - possible to add regex or other pattern support later without breaking compatibility - gives us a quick start with only supporting glob currently stefan >-----Original Message----- >From: Radu Cotescu [mailto:r...@apache.org] >Sent: Tuesday, July 19, 2016 6:26 PM >To: Sling Dev >Subject: Re: [DISCUSS] Path filtering support for ResourceChangeListeners > >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#get >PathMatcher(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 >>> >>>
