These are chat archives for linkeddata/dokieli

7th
Sep 2017
Tim Berners-Lee
@timbl
Sep 07 2017 02:13
We have a simple imperfect proof-of-concept collaborative too l based on Solid patches, with websocket, using the facilities in rdflib.js’s update controller, in the the notepd widget https://github.com/linkeddata/solid-ui/blob/master/src/pad.js
Johannes Wilm
@johanneswilm
Sep 07 2017 05:35
black on black background? I have been clicking around on it for a few minutes, but didn't figure out how I could edit the text. This looks very experimental, but can it handle realtime collaboration? like if two people throw their weight into their keyboard simultaneously? that's what we found to be the tricky part.
Tim Berners-Lee
@timbl
Sep 07 2017 19:13
Black on black background? Strange. I have seen that but I cant remember when. Well, it is better at two people than one person .. it has a recent bug where one person typing fast can mess it up, but it does have the code to listen for changes coming downstream, interleaved with the changes going upstream. When someone, say, deletes a character, a PATCH representing the change goes back to the server. If someone else has just deleted the same character, the pach fails because the change can’t be done to the current graph, and the server returns “409 Conflict” HTTP reponse. The original user’s UI gets backed out — the deleted character is restored (and the line gets a pink background as a warning), and the file is reloaded, and the UI is synced with the file in a non-destructive way — in other words the exising fields which may be haev focuss or being edited are not deleted, just cahnges andnnew elements added/deleted to match te new state.
Johannes Wilm
@johanneswilm
Sep 07 2017 20:28
ok, I get it. yes that was the main difficulty for us as well. Especially in cases where packages get lost or or one client needs to send a second package before it has receive notification on whether the first change was accepted or not it tended to get complicated. the changes are now back to readable. The point of the beforeinput event is that it should give more semantic info about what the user is trying to do. for example, if the user selects half of one paragraph and half of the following paragraph and then types just one letter in a richtext editor, and we only look at the DOM change, it may be difficult to reconstruct what the user was trying to do. The DOOM changes in contenteditable differ from browser to browser and it's full of bugs, so to standardize, one may want to let JavaScript handle the DOM change. But that is difficult to do if all one has to go by is a DOM change which one then has to interprete to find out that the user was trying to type a letter.
Johannes Wilm
@johanneswilm
Sep 07 2017 20:37
or if one wants to do custom behavior. for example, some think that if the caret is directly behind a table, and the user types backspace, it should not immediately delete the table but rather just select it. the argument is that the user may not have seen how many spaces there were and deleting a complex element such as a table is a rather drastic action. so using the beforeinput event and preventdefaulting it, it's possible to implement such custom behavior.
Tim Berners-Lee
@timbl
Sep 07 2017 23:21
The notepad is a linked list of lines, and you can’t select across lines - they are separate input fields. So operations are very simple at the moment, and typically people will be editing different lines and that can all happen concurrently with no problem
@johanneswilm At https://timbl.com/timbl/Public/Test/Pad/pad1/pad.ttl#thisPad do you still get black writing on black background?
If so, in which browser?