It would be possible to extend the Stdio.File() notify api to also support file changes in case inotify is present. However, this only really makes sense if one wants to keep File objects around.
For the higher level abstraction, it might be good to have a look at abstractions that already exist (e.g. gamin, fam). But usually those implement only a subset of what the more advanced interfaces (inotify, kqueue) offer, so i think it would be reasonable to keep that seperate. Also FAM uses filenames, which I would definitely prefer as the general file notification api. I will have a look at extending notify() first and keep everything in the git for now. arne On Sat, 21 Aug 2010, Marcus Agehall (nu med K-m?rkt fastighet och ny elcentral) @ Pike (-) developers forum wrote:
I fully agree with Bill on this one. It's actually pretty useless to have X different interfaces for notifications. We need an abstract interface for it that hides the actual implementation. There isn't all that many variants of file/directory notification APIs, so it shouldn't be too hard to dream up an abstraction. You pretty much need a method to query if the system supports file and/or directory notifications. Then you need a couple of methods to (un)register callbacks when objects in the filesystem changes. If possible, it would also be nice with an even higher abstraction layer, that always allows the user to watch files, regardless if the underlaying implementation supports it or not, but that can wait a bit. As for comitting things to 7.8, it's not a big deal if it doesn't break current APIs, but I'd wait until we got 7.9. It's not too far off.
