LibreOffice from TDF, packaged in RPM, does not have proper dependencies as it
is supposed to be usable on different distros and can't know what names are
used for packages for system libraries used, like the one containing
libdbus-glib. But we must have all dependent libraries installed when running
the loolwsd-systemplate-setup command in the %post phase. As this spec file de
facto is for openSUSE 13.2 only anyway, we can find out the package names and
depend on them...
Add the list from running:
rpm -qf --queryformat '%{NAME} ' `find /opt/libreofficedev5.1 -name '*.so' -o -name '*.so.[0-9]*' | while read file; do ldd $file; done | grep -v dynamic | cut -d " " -f 3 | grep -E '^(/lib|/usr)/' | sort -u`
loleaflet only triggers the loading of the tile, and the tile comes sooner or
later whatever we do, so the idea of aborting the loading does not work until
we have server support for that anyway - let's just kill that for now.
They need to be installed before loolwsd is installed, because our %post
action needs to know where LO is installed so that it can create the
systemplate and child-roots directories on the same file system where LO
is. Oh this is crazy and over-engineered. I wonder if it makes sense at all to
even consider packaging this loolwsd in some generically useful way, or if it
should be considered a manual thing for customers / users to install and
configure.
Sadly the TDF builds of LO use the version number in the package names, so we
can't depend on *some* TDF build of LO (like >= 5.0), but must have a specific
version in this spec file. Sigh.
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.
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...
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.
