minutes of ESC call ...

[Stephan Bergmann]

On 06/12/2014 06:17 PM, Michael Meeks wrote:
> * allow upgrade of access2base (Lionel?)
>      + access2base now included in LibreOffice 4.2 and later
>      + technical structure: one Basic library (and that's it)
>         + for other branches (other forks of OO.org & LibreOffice 4.1 and earlier),
>           available as extension
>      + competitive "disadvantage": users of other branches
>        can have newer access2base faster (install extension)
>      + not possible for LibO 4.2 & later because extension not allowed
>        to override part of LibreOffice (only other extension)
>         + policy exception for access2base can have new features within stable line?
>            + I don't like that
>         + allow extensions to override any part of LibreOffice?
>            + no, significant resistance
>         + demote access2base to bundled extension?
>            + makes Acces2Base much less "official" in LibreOffice :-(
>              (also more work)
>            + problems with bundled extensions in the past (Michael)
>         + allow extensions to override only access2base
>            + Lionel's preferred option.
>            + problem comes from extension using the same name etc. (Stephan)
>                 + mostly a problem with basic modules, not an expert there.
>                 + take Noel's advice from the list.
>                 + ok to add something for access2base, no general fix.
>                      + always troubles with namespaces.
>            + fairly sure this will work well tested it in the build.
>                 + change test of who can override what; done on the file-path
>      + why not make it a bundled extension ? (Michael Stahl)
>            + this is what it was designed for.
>            + why did we move away from bundled extensions ? (Lionel)
>                 + problems with native code bundled extensions (Stephan)
>                 + problems with the upgrade scenarios.
>                 + shouldn't affect basic.
>            + when was this included ? (Stephan)
>                 + was included in 4.2 (Lionel)
>      + switching to bundling in 4.2 is a larger change
>         + vs. a 1-line patch to say it can be overridden (Lionel)
>         + happy with a 1-line change in 4.2 (Michael S)
>            + concerned wrt. the future making it a bundled extension.
> AI:       + merge 1-liner to 4.2 / 4.3 / master (Lionel)
> AI:       + research / seek a saner solution for master (Stephan)

For historic perspective, the case where we ran into massive problems 
with bundled extensions was the (since abandoned) "prereg" feature as 
discussed in <https://bugs.freedesktop.org/show_bug.cgi?id=51252#c35> 
"LO cannot start (reports runtime error with Visual C++ Runtime 
Library)."  From that time comes the current strategy to throw away all 
per-user cached information about any (bundled, shared, per-user) 
extensions and re-build it upon first start after a LO upgrade (which is 
somewhat time-consuming).  That was further reason to reduce the 
back-then large number of bundled extensions we shipped---changing such 
"always included, anyway" functionality from a bundled extension to an 
integral part of the code base reduced brittleness and first-start-time 
(no more need to re-build the per-user cache for that extension), among 
other benefits.

However, in each case where we turned a bundled extension into an 
integral LO-part back then, we were careful to avoid any clashes between 
a functionality's new incarnation as an integral LO-part and its still 
available incarnation as an extension (which a user could still download 
and install independently from the web).  That meant that any names that 
appear in shared namespaces (UNO implementation names etc., potentially 
also .xcs/.xcu configuration data identifiers) were replaced with fresh 
names.

There is, of course, also some downsides in turning functionality from a 
bundled extension into an integral LO-part:  For one, the user can no 
longer update that functionality independently from LO's update cycle. 
(Which is one reason why dictionaries still come as bundled extensions.) 
  For another, the extensions is typically still independently available 
to be installed by an (unsuspecting) user, which can lead to confusion. 
  This can range from somewhat harmless confusion, like two identically 
named menu entries that effectively do the same thing, to more severe 
cases like two competing callbacks being installed for a single 
customization hook and the code not well prepared to handle that.

One source of trouble for the access2base case is that shared-namespace 
names (like names of Basic libraries) were not replaced when turning the 
functionality into an integral LO-part.  This should definitely be 
addressed on master, one way or another.  The various interfaces by 
which extensions (as well as documents containing macros etc.) can plug 
into LO are generally ad-hoc and brittle enough that we should not tempt 
fate with neither careless nor intended-to-be-clever nameclashes.

The remaining question is whether LO should offer the access2base 
functionality in the form of a bundled extension or integral LO-part. 
The historic reasons that lead to the demise of bundled extensions 
should not be too relevant here (similarly to the case of bundled 
dictionaries, say).  One concern would be the update cycles of the 
access2base functionality vs. LO proper.  But a more severe concern 
probably would be whether concurrent installation of the extension and 
the integral LO-part could lead to confusion as described above.  This 
can only be answered by somebody familiar with the actual access2base 
functionality.  If such confusion is to be expected, my recommendation 
would be to go with a bundled extension on master.

Stephan