Hi,
I'm not sure if options 2 + 4 work together without changing the API yet
one more time when / if we decide to also support regex (albeit just a
minor increase). I have nothing against supporting them from the beginning
- unfortunately we don't have a clear separation between API and
implementation here and the API has to anyways state what it supports.
This means that a ResourceChangeListener will support the following ways
for defining a matcher:
1. explicit paths, absolute or relative to search paths
2. '.' , for the cases when the listener is interested in all changes under
the search paths
3. limited glob pattern matching ('*', '**'), by prefixing the pattern with
'glob:'
4. regex matching, by prefixing the pattern with 'regex:'
Did I miss something?
Thanks,
Radu
On Wed, 20 Jul 2016 at 07:09 Carsten Ziegeler <[email protected]> wrote:
> > 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
> >
> Sounds good to me
>
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]
>
>
