Otherwise we have a problem when cached information is different than
the actual one maintained by LOKitDocument, keeping the whole
server setup in an inconsistent state.
For example, when client reloads the browser session quickly
after setting the current part (to say 3) of an opened part document.
If the reload occurs soon enough before the 'setclientpart'
message originated from the client is acknowledged by the server,
then the next reload would get the cached 'status' entry asking
the client to set 'currentpart' to something else leading to the
generation of another 'setclientpart' message. This thing would
go on, and we would run into a loop, as I have for the last few
hours.
Change-Id: Ia6260dfb772f2e3f023572aa060fd7da92b196c8
Reviewed-on: https://gerrit.libreoffice.org/22272
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Now we have 2 caching directories: 'persistent', and 'editing'.
The Persistent cache always represents the document as it is saved, the
Editing one caches the current edits. The Editing state is copied to
Persistent on save. The Editing state is destroyed on reload.
Remove any intersecting cached tiles. It is the parent process that handles
the tile cache, so it must look for invalidatetiles: messages, too, before
passing them on to the client. To know for which part we should remove tiles,
add an "ephemeral" curpart: message that the child process sends to the parent
process before the invalidatetils: message.
Just call the getStatus() function directly in the child process, which will
always cause a complete status: message to be sent to the client. No
documentsizechanged: messages now sent to the client at all.
When a child process sends a documentsizechanged: message to the parent, to be
forwarded to the client, parse it and update a cached status of the doucment,
if available, and send an updated status: message to the client instead.
Note that clients should not rely on getting only status: messages and never
documentsizechanged: messages, though; the cache might be cleaned at any time
even while the server is running. If there is no cached status of the document
to update and re-use, we have to forward the documentsizechanged: message as
such to the client.
The JS code always passes in 0 for now. The server parses the parameter and
calls LibreOfficeKitDocument::setPart() before calling paintTile().
Probably also the status, key, mouse and selection messages will need a part
number. The intent is after all that the protocol is as stateless as
possible. (So maybe we should also pass the document URL in each message?)
