Re: Access2Base - New release

On 13/06/14 11:45, Lionel Elie Mamane wrote:
> On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote:
>
> > 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)
> > and with the previous proposal the possibility that a user could
> > with an extension override say the corporate authorisation macros or
> > whatnot.
> I was exploring / discussing the various possibilities, not having yet
> myself formed an opinion on which one is the best. Given the
> resistance to something general, I made up my mind on something
> "narrow and specific", at least "right now".
>
> (Anyway the user can still "override say the corporate authorisation
>  macros or whatnot" by making a copy of LibreOffice into another
>  folder, changing that copy and running that copy...)
just because there may be some way around this particular example (and
it is only one example) doesn't mean that there is no value in the
application trying to protect it's own internal integrity and certainly
it is no reason to give up it's internal integrity by inviting users to
override it's core (or installed) functionality.
In some corporate environment users don't have access to shell, it's
also very likely that most users don't have the skills to deeply modify
their environment (LD_PRELOAD etc.) I don't believe that just because an
application can in some circumstances (with willful effort by a user) be
led to run code it doesn't expect that it logically follows one should
change the application to actively support running unexpected code
(which is what you are suggesting)
> > 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? They broke it, they can pick
> up the pieces. Similarly, the user can also get themselves in great
> trouble by writing a bomb threat in Writer and mailing to the White
> House. We don't have any protection against that.
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
It's quite simple (all smokescreens about user freedom etc, aside), once
this change is in a release it becomes accepted behaviour. 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. 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
being if indeed the behaviour is accepted as desired )
> 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?
> On a different tack, one difference is that "getting the latest
> Access2Base" is something available to users of other branches of the
> code (LibreOffice 4.1 and earlier, Apache OpenOffice, ...), so here we
> are removing a "competitive disadvantage".
this isn't a justification of why the present behaviour should be broken
just an explanation why it is convenient for you to do that
> 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
> > 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; your opinion is valuable and is
> listened to; for example the narrowing to "make it an exception for
> access2base only".
well actually I beg to differ, it really is a waste of time having a
discussion if in the middle of the discussion the changes being
discussed are made anyway, it's bad form to say the least.
My recently late Dad had a fondness for the expression "there's no point
flogging a dead horse" so I think I'll take his advice. I'm done with this.