WatchService - Exposing more of the Inotify Event Model

[Alan Bateman]

fm wrote:
> Thanks for the response. I figured I'd sign up for the contributor
> status if there was any interest in the modifications I've described
> here.
>   
I can't gauge the interest but it may be best to focus on events that 
may be feasible to implement on more than platform. You could define 
them in ExtendedWatchEventKind a bit like the extensions we have for 
modifiers already.

> :
> I may be misunderstanding you here but the signalEvent(...) method in
> AbstractWatchKey does do "==" comparisons of the WatchEvent.Kind
> argument it receives against the hardcoded StandardWatchEventKind
> types (e.g. MODIFIED, OVERFLOW, and prior redundant events). My
> modification to this method retains exactly the same behavior as
> before; it just moves some of these comparisons into a local method
> called mapsTo(WatchEvent.Kind kind1, WatchEvent.Kind kind2). What this
> does is allow the current WatchService implementations to function as
> they currently do. But I could then override the mapsTo method in the
> LinuxWatchKey implementation to handle the new event kinds I
> introduced in the LinuxWatchEventKind class similarly (e.g., counting
> redundent events).
>   
Right, there is filtering in AbstractWatchKey and I'm just suggesting 
that this (shared) class shouldn't know about non-standard events. We'll 
have to modify the validation as currently it rejects non-standard events.

-Alan.