Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.