Optionally send patches back in websocket pub/sub

[timbl]

We have now the ability to parse N3 patches on upstream changes from the client. (thanks @RubenVerborgh !). We should now also provide an option for the client to ask for other people's changes to the same document to be sent directly over the websocket when the file changes.

• The client uses a variant of "PUB" ("TRACK"?) command over the web socket

• The server takes the patch which has been executed on the file and adds to it metadata such as

• the datetime

• the user making the change, if known, and/or IP address (to allow e.g. change coloring by user)
  (- the etag of the file (or other graph version -- is this actually needed? The patches will be in order -- may be only necessary on teh first one, as the GET the client did was async compared to the websocket open)

The client then applies the patch to the graph.

Compared to the current system, in which the server pings the client that some change has happened, and the client then reloads the file completely, this

• is faster by round trip times across the net, plus
• is faster, for a larger file, by the transmission time of the file.

(This also prepares the ground for future cool developments such as peer-peer distribution of patches between clients, and use of different algorithms for conflict resolution and eventual consistency.)

[RubenVerborgh]

I wonder if we, instead of rolling our own, should base ourselves on an existing well-tested library such as ShareDB (formerly ShareJS, so it's not really a database). I.e., we could write a ShareDB database adapter for Solid. The benefit would be that we don't need to test all concurrency cases etc. ourselves. The drawback that we might not agree with their design decisions (JSON-oriented instead of RDF-oriented).

In any case, we should discuss about a good architecture for this.