On Mon, May 19, 2014 at 04:33:03PM +0200, Michael Stahl wrote: > On 19/05/14 15:59, Lionel Elie Mamane wrote: >> On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: >>> On 19/05/14 08:23, Stephan Bergmann wrote: >>>> On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote:
>>> [...] >>>>> So, the question is "why does this code enforce this condition, >>>>> and can we change it"? Can we just remove the condition >>>>> altogether, or should we add this case: >>>>> || sOriginalUrl.match("$(INST)") >>> (...) you are talking about trying to override a built-in library >>> with an extension, >> Yes. >>> it seems ato me that you are trying to get around the rules of >>> no-new features etc. by exploiting the extension mechanism. >> No, extensions are *very* *much* *designed* to allow addition of >> new features to LibreOffice! > "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. > but when replacing something that's built-in you can't assume that > it was ever designed to be replaced, It's FLOSS, it can always be replaced by a binary-compatible fork of it: a bug fixed, a feature added in a compatible way, a version that logs what the user does, a version that bills printed pages to the appropriate customer (by hooking into the printing function), ... > you can end up with a mixture of built-in files and extension files > loaded that doesn't work. Yes. > 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". 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. 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? >>> But.... in anycase although Access2Base is part of the core, part of >>> the product etc. it is afaik completely selfcontained (and >>> essentially a separately maintained subsystem) in this case I think >>> there is a good argument to bend the rules regarding updating the >>> version of Access2Base shipped, we already do that occasionly I >>> think? >> Well, that means we ship a changing API into our stable line (I mean >> patchlevel updates). I'm not comfortable with this. I'd be far much >> comfortable if people that wanted the changed API installed it >> explicitly as an extension. > then Access2Base should be an extension, they are designed with that in > mind, a bundled extension would have been a better choice, it at least > gives the illusion of being part of the product whilst giving more > flexibility. I don't know what the answer is here, personally I don't > have a problem with Access2Base being updated given what I said above, > but I don't believe replacing non-extension code (be-it binary or > script) with extension code is a good idea See above. -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice