> 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?
>
Looks good, as stated previously I would prefer to not support regex:
for now. We can add it in a later version if really required. And by
using the prefixes we can add it without breaking existing configurations.
Carsten
> 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]
>>
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
