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