When applications are built by sharing access-controlled read-write linked data, it is useful for one application to be informed in real time when another changes the data. By adding real-time publish/subscribe (pub/sub) functionality to the architecture, the system can react in real time without having to poll. The Solid protocol includes a basic but effective form of this using WebSockets, where any app or part of an app which is using data from a given resource can listen for changes to that resource. In 2021, the live update protocol is just a web socket 'PING' notification that the resource has changed, after which the client re-loads it. In future it would be good to instead send a PATCH with the change that had happened, to reduce both the bandwidth necessary and the number of network round trips between client and server. This will allow us to connect to more complex distributed protocols such as Conflict-free Replicated Data Types (CRDTs), and provide offline and Local First functionality in future. But right now a simple WebSocket protocol provides great user value, by allowing all kinds of apps to become live apps.
When applications are built by sharing access-controlled read-write linked data, it is useful for one application to be informed in real time when another changes the data. By adding real-time ability to subscribe to changes, (pub/sub) functionality to the architecture, the system can react in real time without having to poll. This functionality is often known as Collaborative Real-time Editing, and that is an important use case. But the ability to simply have any two displays on sync across the planet when on person is (say) dragging a marker across a map and the other person is watching, synchronized shopping lists, suggest that the value of live update could inspire many moore things than editing documents. When people wrestle over where event should go in a calendar using different Calendar clients (using the CalDAV protocol between them) this is another example of live update.
Live update turns what might have been once a read-only web and is now with Solid common login and access control and HTTP PUT a read-write web, into a live-read-write web
The web socket protocol provide a form of notification. This is a general class of function which spans more or less instant events when you listen for a change within a process (like DOM Events), fairly rapid notifications across the net as in web sockets, and slower forms such as SMS messages, email messages. At the slow end of the scale, protocols like NNTP allow one to subscribe to a feed of news articles. While you can imagine email beings used for aggregated heaps of live-update messages, here we will just talk about the use of fast update, ideally of the order of 100ms.
Live update of the kind Solid aps use to allow collaborative editing and other forms of synchronized display are a really valuable feature. Where we have build development kit stacks and libraries which provide this automatically so that the developer does not have to do anything special, just turn it on, that is ideal. The solid-ui stack does that by building the ability to refresh itself into each widget. Frameworks like React do it by allowing the app coder to write as a function which reads the data once and generates the UI tree in a one-way fashion, and then wrapping that code it is a system which re-applies the function to create whole new DOM tree when the data has changed, and sees to the changed being made in the to the UI are them moved into the real DOM.
The Solid protocol currently includes a basic but effective form of live update using WebSockets, where any app or part of an app which is using data from a given resource can listen for changes to that resource. The live update protocol is just a web socket 'PING' notification that the resource has changed, after which the client re-loads it. In future it would be good to instead send a PATCH with the change that had happened, to resource both the bandwidth necessary and the number of network round trips between client and server. This will allow us to connect to more complex distributed protocols such as CRDTs, and provide offline and Local First functionality.
The current Live Update part of the Solid Protocol provides a very cool basis for building apps in which different users looking at the same thing see synchronized views, allowing Solid Chat to work, and things like shared real-time notepads, and so on, to work. App frameworks like solid-ui and React allow developers to build collaborative real-time apps easily. The functionality in the current protocol could also be improved in future, to be more efficient, and to allow different topologies to the current hub/spoke server/client topology, and to allow offline and "local first" functionality but the current functionality already gives a lot of value.