File watcher extension point

I've previously asked about some fsnotifier behaviour.

We have a couple file systems we'd like to watch that don't support inotify, but that do support other kinds of (custom) watchers. At the moment we have a shim layer at the fsnotifier level, but this doesn't feel like it's the cleanest way to do it, and it's hard to debug.

Would it make sense to break out a file watching interface + extension point that can grab paths and watch them instead of them going to fsnotifier? This way we could ship optional plugins for watching these file systems for users that care about them.

If it makes sense I don't immediately know what would be the cleanest way of associating a path with a particular kind of file system, and how to deal with platform differences. We only support linux, and hard code paths, but that won't fly as a general solution.

4 comments
Comment actions Permalink

In fact the current binary interface (with a documented protocol) was designed to be replaceable and extensible, so, from our point of view, your current solution is a sufficiently clean way to do it.

Having said that, you're welcome to send us a pull request adding this kind of extensibility API. I don't think it's necessary to associate paths with specific filesystems; the easiest solution is simply to propagate watch requests to all registered watchers, and to gather the dirty files from all of them as well.

0
Comment actions Permalink

Thank you for your response.

The current binary interface does have a good protocol, however the deployment is problematic because there's no extension point. We ship by overwriting the binary, which isn't as clean as (say) installing a plugin.

I agree that aggregating all file watchers is a good solution, assuming that each file watcher knows how to reject paths it cannot handle. I think in order to do so I have to do symlink resolution in IntelliJ, otherwise a symlink into a mount point is grabbed by inotify.

0
Comment actions Permalink

You don't actually have to overwrite the binary; you can ship yours side-by-side and specify the path using the idea.filewatcher.executable.path system property. (Or even not ship it with IntelliJ IDEA at all, but rather install it through the global package manager and ship only a modification to idea.properties that points to the new location of the file.)

0
Comment actions Permalink

> You don't actually have to overwrite the binary; you can ship yours side-by-side and specify the path using the idea.filewatcher.executable.path system property. (Or even not ship it with IntelliJ IDEA at all, but rather install it through the global package manager and ship only a modification to idea.properties that points to the new location of the file.)

Unfortunately this is not an entirely satisfactory solution as it requires either packaging a package (i.e. simple drop-a-tarball distribution model is gone and somebody has to maintain apackage) or each user to perform manual steps post-install.
"Use a stock distribution and just install a plugin" is a much nicer model.

Here is a pull request for pluggable file watcher interface: https://github.com/JetBrains/intellij-community/pull/292

0

Please sign in to leave a comment.