Access2Base - New release

[Lionel Elie Mamane]

On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote:
> On 28/05/14 12:11, Lionel Elie Mamane wrote:
>> On Mon, May 19, 2014 at 04:33:03PM +0200, Michael Stahl wrote:
>>> On 19/05/14 15:59, Lionel Elie Mamane wrote:
> [...]

>>> "addition", but not "replacement", especially not "potentially
>>> partial replacement".  with a "bundled extension" it would work to
>>> replace it, because there LO knows the "boundaries" of what is being
>>> replaced and can disable the whole bundled extension;

>> I don't buy that it does that.

>> If (bundled, or system-installed) extension "Foo" ships Basic
>> libraries "Quux" and "Frobotz", and then the user installs
>> extension "Bar" that ships Basic library "Quux", but
>> not "Frobotz", then IMO the result is:

>> 1) Basic library "Quux" from "Foo" is disabled.
>> 2) Basic library "Frobotz" from "Foo" stays enabled.
>> 3) Basic library "Quux" from "Bar" is enabled.

> you are just stating how you want it to work, it's not a
> justification

No, that was my prediction from reading the code that implements
that. I now *tested*, in plain 4.2.4.2 (Debian amd64 package), that it
indeed behaves in that way, by:

1) Installing "Foo" as a user extension
2) Observe result: Libraries Quux And Frobotz (from Foo) are enabled
   and available.
3) Install "Bar" as a user extension
4) Observe result:
   * Library Frobotz is still there and available (from Foo)
   * Library Quux from Foo is nowhere to be found in the Library
     browser.
   * Library Quux from Bar is enabled and present, and can be used.

Now, if I *restart* LibreOffice, it seems to be rather undefined
whether Quux is taken from Foo or from Bar. My guess is that it
depends on the initialisation order of the extensions.

This "depends on initialisation order" undefinedness / problem can (my
guess) not arise in the scenario of an extension overriding a Basic
library in core. I'm much less sure about what happens when:

 * Foo is system-installed or bundled, and Quux is user-installed
 * Foo is bundled and Quux is system-installed

Do we have a well-defined priority order there?

And I'm pretty sure the problem arises when:

 * Foo and Quux are both system-installed
 * Foo and Quux are both user-installed



Another problem:

When I uninstall "Foo", "Bar" is broken. Its "Quux" library is
listed, but empty.


Now, in the scenarios that concern Access2Base, IMO:

1) In the short term, by leaving access2base in core and allowing to
   be overriden by an extension, we avoid the possibility of both the
   above problems.

2) In longer term, people that want to make access2base a bundled
   extension (or some other "saner solution") need to ensure that the
   problem of undefined priority will not arise; I rather expect that
   we have an explicit priority order like:

   bundled yields to system-installed yields to user-installed

   *but* I'd like to have this checked before making access2base a
   bundled extension.


   I *expect* that when the bundled extension and the user (or system)
   installed extensions have the same name, the "uninstall Foo maims
   Bar" problem does not happen, but please ensure that, too.


>>> if you want to bundle something that can be replaced by the user, do
>>> it as a bundled extension.

>> How about we put an exception in the code that only Basic (and
>> Dialog?) libraries, or maybe only access2base, can be overridden by
>> an extension? I don't think we ship any actual feature as Basic
>> code - only examples (I'm less sure about Dialog libraries), so "it
>> will not hurt".

> why should there be an exception for Basic, there is no possibly
> justification for that, oh, hang on I think I can hear it coming, "well
> we don't really ship anything in terms of api with Basic at the moment,
> so... it won't break anything" But it does, there are at least library
> functions and wizards,

OK, if we ship wizards as Basic code, then indeed "exception for
Basic" is not a good idea. I didn't see any from a cursory glance.

> but... in anycase the principle is the same. It all boils down to
> the fact that if you want to provide updated and incompatible api
> then you don't do that in the release branches,

Yes, I agree with that. I want the user to have the *optional*
possibility to go to another / newer API (they are supposed to be
backwards compatible FWIIW).

> that's what master is for, if you want something (e.g. access2base)
> to act like and extension (that provides a different update
> strategy) then just make it an extension

See above.

>> And here, the boundaries are very clear, "known" by the code and
>> handled well by the code: one Basic library.

>> I mean add to the code a case like this:

>>    || sOriginalUrl.match("$(INST)/share/basic")

>> or

>>    || sOriginalUrl.match("$(INST)/share/basic/Access2Base")

>> Or should it be something like

>>    || sOriginalUrl.match("vnd.sun.star.expand:$BRAND_BASE_DIR/share/basic/Access2Base")
>> or
>>    || sOriginalUrl.match("vnd.sun.star.expand:$BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR/basic/Access2Base")

>> ?

>> It avoids us demoting Access2Base to a bundled extension.

> yeah, my feeling here is avoiding this perceived 'demotion' of
> Access2Base is what this debate is about and not a genuine technical
> need or bug. I hope I am wrong. Truth is though.... bundled or not,
> users won't care or notice. Surely the fact that it is supported, it
> is isn't it? (otherwise what's the point??) is IMHO the important
> point or issue for users. That would be what discriminates it from
> other bundled extensions (I bet many users expect are all bundled
> extensions are supported regardless)


>> On Mon, May 19, 2014 at 04:39:36PM +0100, Noel Power wrote:
>>> On 19/05/14 14:59, Lionel Elie Mamane wrote:
>>>> On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote:
>>> [...]
>>>> Access2Base is considered a part of the core isn't it? it isn't
>>>> shipped as an extention, it is shipped as part of the product, (...)
>>>> Access2Base is either part of the product or it's not.
>>>> I don't think this was a very conscious decision. Access2Base started
>>>> its life as an extension that got integrated into LibreOffice, but is
>>>> still available as an extension for other branches / forks of the
>>>> code. It got shipped as part of the product since that was easier to
>>>> set up and LibreOffice was (my perception) moving away from bundled
>>>> extensions anyway.
>>> IMHO moving away == moving functionality into the core => stable api
>>> with the same rules as the rest of the code
>> I tend to agree as to what we ship, but not as to what the user is
>> allowed to override; if (s)he wants to have an updated API by
>> explicitly installing an extension, why not?

> Security, I mentioned it in a previous mail, what you are suggesting is
> basically allowing the user to rootkit the libreoffice api.

I'm surprised you consider LibreOffice a security barrier /
enforcer. I don't. As I see it, factually, it is an application that
runs with the user's identity and privileges, that is under the
control of the user and of anybody that subverts the user's
environment. If you are thinking in terms of security, well LD_PRELOAD
/ LD_LIBRARY_PATH allows overriding any binary part of LibreOffice
anyway. As does LD_PRELOAD'ing a library that redefines open() to
override any part of LibreOffice (Python code, Basic, dialog .ui,
...).

> In the binary case the possibilities should be clear. But even if
> Libreoffice didn't ship any basic libraries as part of the core it
> wouldn't change the fact that enterprises normally deploy all of
> their macros in share, I doubt they would wish that a user could
> 'override' any libraries (including Access2Base that possibly some
> of their macros have a dependency on)

Enterprises are free, if they so wish, to forbid their employees to
install an extension that overrides a part of core, or otherwise
override a part of LibreOffice core.

I think that a (semi-)structured / (semi-)controlled (that is,
extensions) way of overriding more-or-less arbitrary parts of a
program is much better than having to resort to LD_PRELOAD /
LD_LIBRARY_PATH, but that's not my fight, and (obviously) not a change
we'd introduce in a stable branch.

-- 
Lionel