Hi Joerg,
Joerg Budischewski wrote:
Hi,
sorry to warm this topic up again ...
While disagreeing to have such a bootstrap() function in cppuhelper
(this function simply can't work in SDK without office, how should
cppuhelper know, that it is running in an office environment), as it
agreed, the current implementation is more or less suboptimal. The
"bootstrap()" stuff is currently _not_ useable in an URE. Same holds
true for unopkg.
The plan (for OOo 3.0) is, to change "bootstrap()" in a way, that it
provides the currently URE registered components / services / objects,
while simultaneously changing the office to depend on the URE and to
register itself during deployment at the URE.
So, please just regard this as the first steps.
exists, it should be made usable in pyuno.
I have not taken a look at what has been implemented, obviously the
pyuno "bootstrap()" stuff needs to be seamless pyuno. Meaning, that one
should be able to use it in an 100% pure python environment. Certainly
no "cppuhelper" or any such naming should be used.
Christian Junker provided a first patch for bootstrapping with this
function in pyuno (Thank you !, see
http://www.openoffice.org/issues/show_bug.cgi?id=54532 ), but this is
not an ideal solution.
Will take a look later ...
When I use the office context for pyuno bridge, pyuno will get a
performance penalty, because I use e.g. components like TypeConverter
during bridging calls, which will end in multiple overhead remote calls
per pyuno call and pyuno doesn't work anymore when the office is down.
So I need the local context used in bootstrap, but this is unreachable
lost in the cppuhelper bootstrap() function. So the only chance I have
currently is to bootstrap a second context, this is not nice at all and
has other side effects.
Any thoughts ?
See above, pyuno should probably be treated like Java. All the
"bootstrap()" stuff is about getting _the_ ComponentContext. If this is
the context of the underlying URE, or just the one in a 100% pure python
environment may vary, dependent on the usage / deployment scenario.
(Unfortunately we named the "bootstrap()" stuff wrong, as it is _not_
about bootstrapping, but _getting_ a ComponentContext.)
Bye,
Joerg
Kay
Kay Ramme - Sun Germany - Hamburg wrote:
Hi Joerg,
Joerg Budischewski wrote:
I am actually also not sure, whether this belongs in a core api. This
function is a nice helper for starting to program with the office but
it hides too much away imho ( if the office process cannot be
reached, the function loops endlessly, it always an office process
even when an office is running, etc.) to be used in a professional
application.
that bootstrap currently starts an office process is an implementation
detail only. Actually we chose the wrong name for it, when we
implemented it. The right name would have been something like
Reference<XComponentContext> getComponentContext();
The semantics are, that this function returns the systems (which could
be a process, a user, a host, a LAN, a WAN, ...) component context.
The height of the abstraction allows us, to basically implement /
optimize everything behind the scenes, while providing a compelling
and simple to use interface for developers.
In my understanding, especially "professional" developers want to
mostly deal with the customers problem, and less with nasty API details.
Bye,
Joerg
Kay
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
