Hi,
for pyuno, I would address the issue the same way you have addressed it
for the office, thus let python.bat/python.sh set the URE_BOOTSTRAP
variable.
We could even have two python.bat, one that is within the office layer
using all types and one within the ure layer just using ure types but
for simplicitly I would just stick to the one python.bat within the office.
The type-via-remote-bridge-suggestion is certainly a sensible extension,
but won't help here. When you have a component, that can exist without
the soffice process (will there ever be some :-) ... ? ), you would have
to connect to an office just to serve as a type server.
ok ?
Bye,
Joerg
Stephan Bergmann wrote:
The parameterless cppu::defaultBootstrap_InitialComponentContext()
(cppuhelper/inc/cppuhelper/bootstrap.hxx:1.12 l. 95 ff) bootstraps a UNO
environment. When the corresponding cppuhelper dynamic library was
located in an OOo installation, the function happened to bootstrap an
OOo UNO environment, with access to all the OOo UNO types, services, and
singletons. (In its most basic form, when the corresponding cppuhelper
dynamic library is located in a URE installation, the function always
only bootstraps a URE UNO environment, with access to just the basic URE
UNO types, services, and singletons.) Due to the Three-Layer Office
split (see
<http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo>)
starting with DEV300m4 the cppuhelper dynamic library is now always
located in a URE installation, so without further modifications calling
defaultBootstrap_InitialComponentContext() will now always only
bootstrap a URE UNO environment. In some cases, this has already been
addressed nicely or can be addressed nicely, while in other cases it
causes some trouble:
1 soffice itself calls the function. However, soffice sets
URE_BOOTSTRAP to its fundamentalrc, through which URE_MORE_TYPES and
URE_MORE_SERVICES expand to the locations of the additional OOo UNO
types and services.
2 cppuhelper/bootstrap.hxx's cppu::bootstrap calls the function.
However, since cppu::bootstrap itself is typically called within the
"simple bootstrap" scenario
(<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/C%2B%2B/Transparent_Use_of_Office_UNO_Components>),
and unoapploader already must determine the path to an OOo installation
anyway, cppu::bootstrap could be modified to also determine the path to
the OOo installation and set URE_BOOTSTRAP to the OOo fundamentalrc
before calling defaultBootstrap_InitialComponentContext().
3 PyUNO applications call the function (see
<http://www.openoffice.org/issues/show_bug.cgi?id=88211>). Here it is
unclear how defaultBootstrap_InitialComponentContext() could obtain the
necessary information about a OOo installation to actually bootstrap a
OOo UNO environment. One bad hack would be to re-use the
soffice-finding mechanism from unoapploader here, too, but that can
easily fail in finding no OOo installation at all or an outdated or
otherwise inappropriate one (if you have more than one installed).
So, the following dawned on me: In many scenarios
defaultBootstrap_InitialComponentContext() is called by a client
application that will connect against soffice, use only UNO services it
obtains remotely from soffice (apart from the fundamental ones already
provided by URE), and needs access to all the OOo UNO types. All of
this can easily be served by a
defaultBootstrap_InitialComponentContext() that only boostraps a URE UNO
environment, except for the access to the additional OOo UNO types. But
cannot we solve this last bit by dynamically transporting UNO type
information across bridges (something that is on our wish list for quite
some time already)? I think so.
The question remains: If UNO types can finally be transported
dynamically across bridges, are there any calls to
defaultBootstrap_InitialComponentContext() for which it would not
suffice that merely a URE UNO environment is bootstrapped (apart from
the trivial ones like soffice itself that can easily set URE_BOOTSTRAP
to point to an OOo installation)?
What do you think?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
