A pub notification is not triggered when a file changes

[melvincarvalho]

From my experimentation pub notifications are triggered, in some, but not all cases of an underlying file changing

For example when a PUT/PATCH/DELETE operation occurs, then a pub notification is delivered

However, if the file is changed on the file system then the watching client would be normally unaware that such a change has been made, leading to potentially inconsistent states or conflicts

One way to mitigate this would be to watch the file system and have that as an additional input to the pub / sub mechanism. In my experimentation, this works well, but the only caveat is that there are OS level configurations of the number of files that can be watched, but this can be easily raised, there is a slight memory overhead of a few bytes per file.

Another method I've used is to "touch" a file when it is updated on the OS. You can do this (hopefully!) by sending an empty PATCH to a file. However, the disadvantage of this approach is that the latency for update increases, it involves an extra moving part, can be more resource-intensive, and PATCH can be buggy.

It would be great if full realtime updates could be considered in node solid server. This is something I use on a daily basis, and it would be nice not to have to use workarounds. It's not hard to imagine a plethora of use cases for realtime updates : realtime decentralized chat, markets of changing products, media updates and slideshows, playlists and so on.

[tmciver]

This feature might make sense for NSS which is file-based but that is an implementation detail and not part of the Solid spec, correct? If so, I would think that the only way a file in NSS can be changed is through the API. What are scenarios where an NSS file is changed not via the API?

[melvincarvalho]

@tmciver thanks for the comment.

On the web, and therefore, in solid, both the file: and http: URI spaces are first class. Meaning that they should both be part of your data space and interactions, both read and write. @timbl has referred to your file system, I believe, as the "0th pod". I like this (correct me if I've got that wrong).

Both http: and file: point to an underlying resource. The idea of the websocket is to provide a real time update when that resource is changed. If you think about it, you might end up with an out of sync client otherwise.

Say you take a photo, and it's not part of the slideshow you want to share, that becomes a bad UX. Or say you are updating some code in realtime via an IDE (e.g. using fuse or many ides can connect remotely these days), and you want to show those live changes.

So logically, when using our simple pub sub protocol, if working correctly, if something changes downstream, you should get an update in the front end.