Re: Access2Base - New release

On 28/05/14 12:11, Lionel Elie Mamane wrote:
> On Mon, May 19, 2014 at 04:33:03PM +0200, Michael Stahl wrote:
> > On 19/05/14 15:59, Lionel Elie Mamane wrote:
[...]
> > "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.
huh? extensions are built on top of and using the stable (well as stable
as libreoffice ever is) api, if you allow 'other' extensions to change
the 'core' api (with no way of knowing that the base system has been
changed) then.... well good luck with stability
>  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.
you are just stating how you want it to work, it's not a justification
> > 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), ...
I don't even understand the argument, but... hey if you are saying that
someone can build various libraries and components and shove them into a
libreoffice installation then sure, they could do it, they are free to
do it but would you actually provide support for them to do that
> > 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".
why should there be an exception for Basic, there is no possibly
justification for that, oh, hang on I think I can hear it coming, "well
we don't really ship anything in terms of api with Basic at the moment,
so... it won't break anything" But it does, there are at least library
functions and wizards, but... in anycase the principle is the same. It
all boils down to the fact that if you want to provide updated and
incompatible api then you don't do that in the release branches, that's
what master is for, if you want something (e.g. access2base) to act like
and extension (that provides a different update strategy) then just make
it an extension
> 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.
yeah, my feeling here is avoiding this perceived 'demotion' of
Access2Base is what this debate is about and not a genuine technical
need or bug. I hope I am wrong. Truth is though.... bundled or not,
users won't care or notice. Surely the fact that it is supported, it is
isn't it? (otherwise what's the point??) is IMHO the important point or
issue for users. That would be what discriminates it from other bundled
extensions (I bet many users expect are all bundled extensions are
supported regardless)
> 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?

Security, I mentioned it in a previous mail, what you are suggesting is
basically allowing the user to rootkit the libreoffice api. In the
binary case the possibilities should be clear. But even if Libreoffice
didn't ship any basic libraries as part of the core it wouldn't change
the fact that enterprises normally deploy all of their macros in share,
I doubt they would wish that a user could 'override' any libraries
(including Access2Base that possibly some of their macros have a
dependency on)

Noel