There is actually the equivalent of web sockets in Notes Client applications, I'll call it "client sockets". Again though, most developers would probably not be aware of it. It's managed in the View properties, in the "Refresh Index" and "On Refresh" property on the Options tab of View properties.
- Any automatic "Refresh Index" option with any refresh display setting for "On Refresh" will enable "client sockets" - the server pushes the change to users immediately, whether the change is made on another client, on a browser, via an agent, whatever.
- Any automatic "Refresh Index" option with the "Display indicator" setting for "On Refresh" will enable client sockets only for the top left square of the Notes View: the server pushes the familiar blue arrow to say an update is available on the server. But the user gets to choose when to pull the update from the server.
- The "Manual" option for "Refresh Index" will turn off indexing on the server, and thus "client sockets".
Another point worth emphasising here is that all clients hold all of the view.
Domino "Just Does It For You" and, because it pre-dated pervasiveness of the web, let alone web sockets, it hides the similarity to web sockets from developers and also hides the complexity.
Web Sockets in Architecture
It's worth reviewing the architecture from our application at IBM Think and Engage.
Note that the Web Socket server is a layer between our React app and Node-RED. Node-RED was where all interfaces - the React app and the Watson Workspace integration - went through. The Watson Workspace integration pushed not only to the API gateway on Domino, but also to the Web Socket server. This meant any changes to the application were instantly available on all connected browsers, whether they were made from the current browser, from another browser or from Watson Workspace.
Note that we had no XPages interface and no Notes Client interface. Any changes there would not be pushed to the Web Socket server, so would never get pushed to the connected browser. They would only get pulled when a fresh request to the API gateway was made.
If memory serves me correctly, I don't think we were chunking the view either. A request to the API gateway passed the whole view. So filtering happened against the stored state in the Node.js app. This may have a relevance, I don't yet understand the inner workings of web sockets to offer a definitive answer. But it seems plausible that it might have an impact.
Things get more difficult in XPages. XPages does not have a live link to the view on the server. It keeps its state based on persistence settings, as I mentioned in the first blog post of this series. That may be in memory or on disk.
Updating the browser seems easy as a push, but it would need to be something separate from the XPages runtime. So how does it hook into the XPages runtime? What if you're using a repeat control that's a ViewEntryCollection or ViewNavigator? How easy would that be to push from the server? And what if you've created a repeat control based on a ViewEntryCollection that includes editable components or buttons to allow you to effectively have "InViewEdit"? John and I had that in our React app, but it worked because our web sockets server was updating the server-side local storage. How do you update the in memory storage of the XPages collection? And would you corrupt the partial refresh process by doing so?
And any updates also have to go through that web sockets part.
Presumably there would also be similar challenges with Java frameworks and Proton.
The Pub Sub functionality may be the key here.
Notes Client will get immediate updates, where coded, because Domino "Just Does It For You".
For your web applications, you code your own web socket server - in Node.js, Vert.x, whatever. You route all instances of your web applications through it. And you subscribe to the Pub Sub functionality for any CRUD changes to the underlying NSF, pushing the update to your web socket server. If your REST API that third parties want to connect to wants to offer subscribe functionality, again, that routes through your web socket server, and it handles it. If it doesn't, you just write to the NSF and the Domino server's pub sub pushes it to the subscriber which pushes it to the web socket server. If you have a basic web application that doesn't need web sockets, it continues as is.
Yes, this is more work. But it ensures your custom application has the custom requirements you want.
Maybe HCL - or the community on OpenNTF - can provide a starter module in the language of your choice. But I suspect it probably needs to be done by the community.
If you want HCL to build a web socket server into the core that addresses all use cases and doesn't break anything, and supports things like XPages because that's still being maintained, with a GUI and editors that makes it as easy as Notes developers expect, I doubt it'll happen any time soon.