The only difficulty i see is that in order to get notifications on file changes, with only dnotify present it would be necessary to watch the directory it contains and filter only changes to this file.

It would be simple though to extend the Stdio.File()->notify to use inotify for file changes if present. This would most likely not break any existing code, since it currently works only on diretories.

On Fri, 20 Aug 2010, Bill Welliver wrote:

It would be nice if we could come up with an abstract interface so if someone were to write an interface to, say, FSEvents in OSX or FEN on Solaris, a developer could write common code that would work on multiple OSen.

That said, it could be a layer on top of whatever existing notification modules were written, so it wouldn't necessarily preclude action on this particular request.

Bill

On Fri, 20 Aug 2010, Arne Goedeke wrote:

...

I merged the Public.System.Inotify module into pike as System.Inotify. Its currently only in my git. You can fetch the branch called 'inotify' at http://laramies.com/git/pike/

I would like to commit this into cvs. However, it seems to me that the current policy is not to commit anything new until 7.9 is there? Also, right now it is seperate from the dnotify in Stdio. The inotify api is different from dnotify, so it might not be possible to merge that.

All comments on the code welcome.

arne

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.

2010/8/26 Arne Goedeke el@laramies.com:

Maybe someone can elaborate on how this is supposed to be used.

I tried to look at the test cases, but there weren't any unfortunately.