Access2Base - New release

[Lionel Elie Mamane]

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