Introduce a bit of hierarchy there, at some stage we'll want to re-order the
tile requests a bit so that it works better for collaborative editing; for the
moment, removing the duplicate entries is enough.
The commands leave the parent's queue very quickly, the child's queue is the
critical one, so remove them also from there. This speeds up the typing
experience very considerably.
To be on the safe side, I only allowed "uno" previously, but Mihai
confirmed that the intention was to filter out "tile" duplicates, so
filter out only that.
Problem since commit 8f48dabf28 (loolwsd:
discard requests that are in the queue already, 2015-07-21), e.g.
"select-all, paste, select-all" doesn't have the same meaning as
"select-all, paste".
Quite possibly the condition should be inverted, and filtering out
should be done only for a few commands, like "tile"; but at least
filtering out "uno" is definitely problematic.
Having a URL like file:///tmp/tmp13630baaaaa/test.txt allows retaining
the filename given by the user and still work with a URL.
We could try carrying around a memory buffer, but we would still have to
send it over the WS, so it's easier if we always work with URLs instead.
When requested, the document is exported under
/jail_path/CHILD_ID/user/thedocument/RANDOMDIR/filename
and CHILD_ID, RANDOMDIR and the filename are communicated to the client.
When the client requests
http://server:port/CHILD_ID/RANDOMDIR/filename, the exported document
is served and then RANDOMDIR is removed
when used with --test option:
./loolwsd --test --systemplate=${SYSTEMPLATE} --lotemplate=${MASTER}/instdir
--childroot=${ROOTFORJAILS}
ensure that one child is created and attach to it easily to debug lokit
messages
Implementing this Was harder than I first expected. The basic idea is as
follows: The master process puts each message arriving from a client that
isn't "canceltiles" into a (client-specific) queue. A separate thread that
pulls messages from the queue at its own pace and handles them as
before. Incoming "canceltiles" messages are handled specially, though: The
queue is emptied of "tile" messages.
The above sounds simple but there are several details that were a bit tricky
to get right.
Why did I wait so long to do this? This is obviously the right thing to do, I
hope, and has a very significant impact on the robustness of the server...
