LibreOfficeKit and the UserInstallation

[Miklos Vajna]

Hi Stephan,

On Wed, Mar 23, 2016 at 03:30:50PM +0100, Stephan Bergmann <sbergman at redhat.com> wrote:
> Therefore, I would like somebody overseeing the architecture of LOK to
> explain how LOK intends to solve its "multiple processes per
> UserInstallation" problem.

There are two main use-cases for LOK at the moment: Android and Online.

In the Android case there can't be multiple processes using LOK. If a
document is opened and a second document would be opened, then the OS
takes care of forwarding this request to the already running app. So no
need for the OfficeIPCThread stuff, we just want to know when
LibreOffice startup is ready. As you already saw, lo_initialize() uses
it to wait till LibreOffice starts up (on the "soffice thread" that's
the main thread in the desktop case), but if there is an other way to
get notification about when startup is ready, that's also fine.

In the Online case, LOK is initialized in a process that runs in a
chroot, and it always gets an empty user profile (that was the need to
introduce a custom profile location in the LOK API initially). Given
that we just create the user profile, we can be sure that nobody else is
using it: so again just lo_initialize() uses the OfficeIPCThread stuff.

So as far as I'm aware, in both main use cases, we just assume that the
user profile is not used by anyone else (either because the OS kind of
gives a guarantee for that, or because the profile path is a unique one
we just created), that's why there is no explicit code handling that.

You're right that in case you use LOK on the desktop, e.g. via
<https://github.com/ojwb/lloconv>, and soffice is already running, then
we have a problem -- this situation is not handled at the moment, so
whatever rework would be needed for xdg-app, you can ignore this case.

Wrt. killing the OfficeIPCThread stuff, as long as lo_initialize() is
adapted so that it uses some other reliable way to determine when LO
started up, it doesn't need it, either. If the LOK startup logic needs
debugging, then either the in-tree gtktiledviewer or the above lloconv
is probably the easiest tools to trigger that code: both Android and
Online are complex to set up, and relatively complex to debug as well.

[ In case a precise definition is needed for "started up", I guess what
we really assume there is:

1) comphelper::getProcessComponentContext() returns something
meaningful.

2) Global services like css.frame.Desktop are available.

It seems these are true after OfficeIPCThread::WaitForReady() returns. ]

Regards,

Miklos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20160323/ef286818/attachment.sig>