Hi,
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.
main problem I see here is, that there won't be THE component context
(think about several uno apps installed on one system, in general it is
not sensible or even not possible to merge all services ...), so I don't
think that a function without arguments will work out, but we will see ...
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.
The bridge currently needs the stoc scripting components, so there is no
100% pure python pyuno ( this is certainly a nice aim, but would need a
lot of more coding, e.g. a pure python remote bridge implementation and
a python reimplementation of the core components (servicemanager,
component context, implementation registration, etc., url-resolver and
friends ).
So cppuhelper is currently eitherway required, no problem to
additionally depend on another function within cppuhelper.
So there are 2 possibilities,
1) adding another bootstrap() function in cppuhelper that exports local
and remote context
2) reimplementing it in pure python.
2) has the disadvantage that we implement and maintain this peace of
code a 3rd time, but I think we should go for it as Christian suggested,
so we don't need to uglify cppuhelper with another function.
@Christian: I personally would prefer not to add it to uno.py or
unohelper.py but instead create a new file (e.g. officehelper.py or
maybe some other name, suggestions ?), where also later more office
relevant helper functions can be added. It would cleanly separate the
office from the uno core. The challenge is to implement it platform
independent, if this can be done, I'd also prefer a pure python
implementation.
Usage in a client script would be
import officehelper
remoteCtx = officehelper.bootstrap() #
....
The implementation of bootstrap() would call uno.getComponentContext()
just as any other current pyuno script and then do the rest 'by hand',
so no change in the pyuno core is required. What do you think ? Can you
implement such a function ?
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
