Access2Base - New release

[Lionel Elie Mamane]

On Mon, Jun 16, 2014 at 09:53:37AM +0100, Noel Power wrote:
> On 13/06/14 11:45, Lionel Elie Mamane wrote:
> > On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote:

>>> But, as I see this morning this discussion is a waste of my time,
>>> seems that this change was already in, why even bother asking for
>>> an opinion in the first place, unfortunately I find I am not
>>> surprised

>> No, it is not a waste of time;

> well actually I beg to differ, (...) I'm done with this.

I'm sorry we are losing your input on the design of the long-term
solution in master (as opposed to the stop-gap that went in).

> >> Anyway, since binary overriding isn't on the table yet my main
> >> concern was with basic where you have can have Libraries deployed in
> >> share by the enterprise, (...)
> > I'm not sure what "deployed in share" means. An extension installed
> > "for all users" / with "unopkg --shared"? I sense that this is not
> > what you mean. Maybe by just dropping a directory + files in
> > LibreOffice's $(instdir)/share/basic/ ? I hadn't thought of that as a
> > good way to extend LibreOffice... Is that really how it is done?
> how is Access2Base delivered? (I actually don't know) but I presume it
> like the wizards and other basic utilities that it is located in
> $(instdir)/share/basic.
> That is the also location where Enterprise's will also deploy their
> macros so that they are picked up by *all* users (or at least that is
> where they used to do that)

I hadn't anticipated people/enterprises would to it like that. I'm
trying to imagine how it would work in practice...

On RPM/DEB GNU/Linux systems, dropping files in (example for Debian)
/usr/lib/ ($(inst) is /usr/lib/libreoffice apparently) is heavily
discouraged... Unless one does it through a deb/rpm package. That's
why (in my worldview) most programs look for "files" in a second
location, namely /usr/local/something, which is reserved for the
admin. AFAIK, LibreOffice doesn't do that, I understood that the
extension package kinda "replaces" that.

On Microsoft Windows, you'd have to drop files in
"c:\progra~1\LibreOffice 4\share", and then move them when you
upgrade to LibreOffice 5, etc.

>>> Above you concede that allowing this in Basic generally is
>>> probably not a good idea. But... still you propose to special case
>>> this overriding for Access2Base, I can't see how it is any
>>> different, the same argument holds and users can easily break
>>> deployed macros depending on the 'installed' version of
>>> Access2Base.

>> Yes, especially when installing an older version of Access2Base
>> than the one in core. Why is that a problem?

> The problem is that to get into that situation in the first place
> you have had to allow the user to override the core behaviour with
> an extension, isn't that the what this discussion is all about
> (wasn't the first question in this thread about why there is a piece
> of code that enforces that such a scenario doesn't occur)? It's not
> about Access2Base at all (although it is obviously the trigger) it's
> about changing the defined behaviour (even in a limited way that
> effects just Access2Base) where user extensions can override/replace
> core functionality

Well, Access2Base was my goal ("trigger") in opening the discussion;
to understand the problems and concepts, I generalised them. In other
words, I looked at, and discussed, the "general case" to understand
what could be done in the specific.

> It's quite simple (...), once this change is in a release it becomes
> accepted behaviour.

What is intended to become accepted behaviour, at a higher level, is that
access2base can be upgraded "out of cycle", by the admin and/or user,
in LibreOffice. Not the particular way in which it is done.

> It's then only a matter of time before the expectation is that it
> should work the same way for the rest of Basic, and then for
> consistency an expectation of the same behaviour for binary
> extensions an so on.

I don't expect such a narrow exception will lead to a slippery
slope. And if we find a better way, we can remove the exception and
allow "upgrading access2base" in some other, better, way in 4.4.

> Given your expressed views that this is how you would like the
> application to behave anyway, I find this change worrying to say the
> least ( caveat abeing if indeed the behaviour is accepted as desired
> )

I'm not the LibreOffice benevolent dictator (thus my views will not
have priority), and I don't intend to push for the general case
anyway. About the general case, I floated the idea, others disagree,
<shrug>

>> The user can also make their environment unusable by changing the
>> UI language to a language they don't understand. And a myriad other
>> things...

> so what?

So trying to protect the user from themselves (which you intend to do
by having LibreOffice "try to protect its own internal integrity") is
a loosing battle, and is not worth making the "hacker user"'s life
more miserable.

>> If we consider a macro written for (and that works only with) the
>> "latest Access2Base", then it allows the user to use that macro
>> with LibreOffice 4.2, without having to upgrade to a less tested
>> LibreOffice 4.3.

> wouldn't it make more sense then to update *all* branches to the
> latest access2base, if it don't change that much anyway

I'm deeply uncomfortable with us shipping a changing API within a
release branch. Access2Base is designed to be backwards-compatible
(modulo bugs that all software has...), but not upwards-compatible. By
upgrading LibreOffice within e.g. 4.2.5, we abandon the property that
macros developed against 4.2.5 will also work (modulo bugs) with
4.2.3.

-- 
Lionel