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.