Hi Stephan,
Stephan Bergmann wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
[...]
Anyway, even using the mentioned registry entry does not seem to
achieve what you want to achieve, as this registry entry is globally
unique and does not belong to the office installation. So, what you
actually want, is an OOo installation specific entry, which points to
the to be used URE.
No, not necessarily. (If OOo-wo-URE wants to store a pointer to its
underlying URE, it need not use the registry at all.) Let me rephrase
my thoughts:
Sure :-)
There are three steps involved. First, when OOo-wo-URE is installed, it
needs an installed URE, so that needs to be found somehow (and
HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE pointing at "the machine's
default URE" might come in handy here). Second, OOo-wo-URE needs to
Yes, agreed, that's what I meant.
have this information (i.e., the location of its underlying URE)
available at runtime. And third, it should be easy for the user to
change that information, to at least be able to (a) at installation time
combine the OOo-wo-URE with an arbitrary URE (not necessarily "the
machine's default URE"), and (b) later on move around the installation
locations of the OOo-wo-URE or its underlying URE, or both.
My understanding of windows registry entries is, that they actually
serve (or at least partly do so) the same purpose as the deployment
parameters. In the sense, that if a user wants to change the URE to be
used by a particular office installation, he/she would change a registry
entry of that installation for that reason.
Anyway, we certainly can say, that registry entries are just for finding
particular installations, with the consequence, that we would only
_reference_ the HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE somehow.
If we do that centrally, like in bootstrap.ini, we would ensure that
only a single place needs to be changed to switch from one URE to
another. So, I am not sure yet, how to solve the binary stuff etc., may
be Hennes customer loader thing can do look up through the appropriate
bootstrap variable? Unfortunately this may lead to bootstrapping
problems because of cycle dependencies (the office libraries needing to
find the bootstrap parameters to resolve the boostrap parameters).
By the way, if we put that whole thing from its head to its feed,
basically registering the office services into a particular URE
installation, the above problems seem to vanish ... ;-)
AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an
OOo installation specific registry entry, and, as you already
suggested, to introduce .ini files for all executables, so the latter
may be avoided by seamless integration/support of windows registry
entries into the deployment parameter approach.
Not sure about OOo storing its deployment data in the registry. What
would the keys look like? What about having two instances of OOo
installed that are "sufficiently similar" from a code-base point of view
(i.e., would probably both use the same keys), but nevertheless shall
have different deployment data?
You certainly would need different registry entries for different
installations, while having one global entry pointing to the "default"
installation.
-Stephan
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
