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
exists, it should be made usable in pyuno.
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.
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 ?
Bye,
Joerg
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]
