Re: LibreOfficeKit and the UserInstallation

[Pranav Kant]

Hi,

On Tue, Apr 19, 2016 at 1:48 PM, Miklos Vajna 
wrote:

> Hi,
>
> On Wed, Mar 30, 2016 at 10:30:46AM +0200, Stephan Bergmann <
> sberg...@redhat.com> wrote:
> > That is, at least the use case of the lokdocview widget in
> gnome-documents
> > has always been broken and needs a fix.
>
> I've fixed the widget part of that now in
> df784ec1bf3d1745a291056df28bec799d4fdee3. Clients has to provide a user
> profile URL, and they need to make sure that profile is only used by
> them.
>

Awesome ! Thanks


>
> Pranav, is it worth to backport this to libreoffice-5-1? I can propose
> that, but only in case gnome-documents is probable to actually use the
> userprofileurl property.
>

Yeah, would be good to have it back-ported, if possible.



>
> Regards,
>
> Miklos
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>


-- 
Regards,
Pranav Kant
http://pranavk.me
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Miklos Vajna]

Hi,

On Wed, Mar 30, 2016 at 10:30:46AM +0200, Stephan Bergmann 
 wrote:
> That is, at least the use case of the lokdocview widget in gnome-documents
> has always been broken and needs a fix.

I've fixed the widget part of that now in
df784ec1bf3d1745a291056df28bec799d4fdee3. Clients has to provide a user
profile URL, and they need to make sure that profile is only used by
them.

Pranav, is it worth to backport this to libreoffice-5-1? I can propose
that, but only in case gnome-documents is probable to actually use the
userprofileurl property.

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Stephan Bergmann]

On 03/23/2016 03:30 PM, Stephan Bergmann wrote:

The next line of defence happens to be that LOK apparently bootstraps
enough of the LO code to make the OfficeIPCThread code come into play,
cf.

"Use OfficeIPCThread::WaitForReady rather than sleeping" etc.


Turns out I wasn't quite right there.  Upon closer inspection, 
OfficeIPCThread's defence against multiple processes operating on the 
same UserInstallation had explicitly been disabled for LOK with 
 
"Don't use any IPC pipe when in console-only mode or in a LOKit-based 
program" et al.


That is, at least the use case of the lokdocview widget in 
gnome-documents has always been broken and needs a fix.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Stephan Bergmann]

On 03/23/2016 04:40 PM, Miklos Vajna wrote:

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.


Extracted the launching of the pipe reader thread, so that all what LOK 
now does is the WaitForReady part; 
 
"Don't launch the PipeReaderThread from LOK".

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Thorsten Behrens]

Miklos Vajna wrote:
> On Wed, Mar 23, 2016 at 03:30:50PM +0100, Stephan Bergmann 
>  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.
>
It's also quite convenient for e.g. document conversion. Having a
throw-away user config would therefore be quite nice (or some
in-memory or read-only version of it). I guess that would also
squarely fit gnome-document's use case.

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Pranav Kant]

On Wed, Mar 23, 2016 at 9:18 PM, Miklos Vajna 
wrote:

> Hi,
>
> On Wed, Mar 23, 2016 at 04:43:39PM +0100, Michael Stahl 
> wrote:
> > > There are two main use-cases for LOK at the moment: Android and Online.
> >
> > what about gnome-documents?
>
> I'm afraid gnome-documents currently assumes that soffice is not running
> when it uses LOK.
>

> Pranav, is the above still up to date info, or in the meantime
> gnome-documents started to set the user profile to some private location
> to allow gnome-documents and soffice running in parallel?
>

No, gnome-documents does not set any user profile to any private location
as of now.
(It does nothing on its own except using the lokdocview widget)


>
> Regards,
>
> Miklos
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>


-- 
Regards,
Pranav Kant
http://pranavk.me
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Miklos Vajna]

Hi,

On Wed, Mar 23, 2016 at 04:43:39PM +0100, Michael Stahl  
wrote:
> > There are two main use-cases for LOK at the moment: Android and Online.
> 
> what about gnome-documents?

I'm afraid gnome-documents currently assumes that soffice is not running
when it uses LOK.

Pranav, is the above still up to date info, or in the meantime
gnome-documents started to set the user profile to some private location
to allow gnome-documents and soffice running in parallel?

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Michael Stahl]

On 23.03.2016 16:40, Miklos Vajna wrote:
> Hi Stephan,
> 
> On Wed, Mar 23, 2016 at 03:30:50PM +0100, Stephan Bergmann 
>  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.

what about gnome-documents?


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeKit and the UserInstallation

[Miklos Vajna]

Hi Stephan,

On Wed, Mar 23, 2016 at 03:30:50PM +0100, Stephan Bergmann 
 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
, 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


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

LibreOfficeKit and the UserInstallation

[Stephan Bergmann]

A LO UserInstallation must not be accessed concurrently by multiple 
processes (at least not when at least one of them potentially modifies 
it).  LO itself ensures that with the first soffice instance listening 
on a well-known pipe (whose name depends on the UserInstallation path, 
among other things), and any subsequently started ones dispatching their 
command line arguments to that first one (the "OfficeIPCThread" code, 
desktop/source/app/officeipcthread.hxx).


I don't know how LOK wants to ensure that, though.

One obvious approach is giving different processes different (throwaway) 
UserInstallations.  There is code that sets the UserInstallation 
bootstrap variable in LOK's lo_initialize (desktop/source/lib/init.cxx) 
when the passed-in pUserProfilePath is non-null.  However, tracing back 
the callers of lo_initialize:


* smoketest/libtest.cxx calls lok_preinit with a null user_profile_path
* sal/android/libreofficekit-jni.c calls libreofficekit_hook (implicitly 
passing null)
* ios/experimental/TiledLibreOffice/TiledLibreOffice/AppDelegate.m and 
libreofficekit/source/gtk/lokdocview.cxx call lok_init (implicitly 
passing null)
* libreofficekit/qa/tilebench/tilebench.cxx, 
libreofficekit/qa/unit/tiledrendering.cxx, and smoketest/libtest.cxx 
call lok_cpp_init with a (defaulted) null pUserProfilePath


That is, not overriding the default UserInstallation seems to be 
encouraged rather than being prevented when using LOK.


The next line of defence happens to be that LOK apparently bootstraps 
enough of the LO code to make the OfficeIPCThread code come into play, 
cf. 
 
"Use OfficeIPCThread::WaitForReady rather than sleeping" etc.


However, "happens to" because that OfficeIPCThread code is rather a mess 
that, in addition to the pipe stuff explained above, also is central to 
LO's lifecycle management.  And it is rather this second part that LOK 
is interested in.  Or, rather, that it needs to get its head wrapped 
around, as the LO code that LOK bootstraps somewhat unhelpfully insists 
on getting the OfficeIPCThread code involved---all that the LOK code 
apparently wants is to be notified once the LO code is bootstrapped, and 
OfficeIPCThread::WaitForReady happens to be a convenient way to get that 
done.


I think LOK would be better off not starting off that OfficeIPCThread 
pipe listening stuff at all.  (It is most certainly not intended that 
soffice and non-soffice LOK processes happily pass their command line 
arguments to each other for processing.)  And 
 
"Add a comment" appears to agree with me on that.


I got dragged into this when trying to untangle the OfficeIPCThread 
mess.  Running LO under xdg-app will require to optionally use DBus 
instead of a named pipe in the OfficeIPCThread code, but adding that is 
unnecessarily difficult with the current state of the code.  So, while 
at it, I thought I could just as well see to get LOK's unwanted 
dependency on OfficeIPCThread removed.


Therefore, I would like somebody overseeing the architecture of LOK to 
explain how LOK intends to solve its "multiple processes per 
UserInstallation" problem.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice