Access2Base - New release

[Lionel Elie Mamane]

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)")

>>> Noel? Uray? You are our Basic "FindTheExpert"s. What's your
>>> opinion on this?

> It seems to me that the code there (which I admit I am not familiar
> with) is all to do with extensions and management of extensions
> right? In this case you are talking about trying to override a
> built-in library with an extension,

Yes.

> the code it would seem rightly tries to prevent an extension from
> doing that. I mean there are wizards, conversions, routines
> etc. that are considered part of the system that shouldn't be
> 'replaced' under the hood.

Naively, why not? If an extension wants to improve one of our wizards
or conversion, why forbid it?

> 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.

> 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!

> Also doesn't the code mentioned above actually try and remove the
> existing library? perhaps the librarycontainer does something
> special in this case, I don't know.

Yes, it removes the existing library. I tried it (by changing the code
flow to go into the "if" instead of the "else"), and it "just
works". The "part of the product" library just disappears from the
"LibreOffice Macros" list, and the one from the extension goes into
"My Macros" (for a user-installed extension). When the extension is
removed, after a restart of LibreOffice the "part of the product"
library appears again.

> 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.

>> Most likely, the reason that that desktop/source/deployment code only
>> checks against existing extension libraries but not built-in ones is
>> that that was never a use-case the code was designed for.  I do not
>> know, though,whether there are any gotchas on the BASIC side that
>> would be enabled by your proposed change.

> <shrug> I'm not sure, I know any duplicate symbols (and it can happen in
> libreoffice basic) can cause unexpected and suprising results, imho they
> shouldn't be allowed but that's another story. I'm still not sure what
> actually happens when such a scenario as above is forced, is the 'old'
> library removed or not,

See above. "removed", I would rather say "disabled" as long as the
extension is installed.

> if not does the 'old' library actually get compiled even,

n/a

> what happens later when upgrading,

Not tested, but I guess the library from the extension continues to
override the built-in one.

> does it set a precedent for binary extensions to be able to replace
> 'system' components (if that isn't already possible) etc.

Maybe I'm naive, but I'm in principle OK with that; an extension that
breaks something when doing that gets to pick up the pieces.

-- 
Lionel