Hi, 2005/9/24, Joerg Budischewski <[EMAIL PROTECTED]>: > Hi, > > sorry to warm this topic up again ...
Why sorry? I think this topic is worth discussing. > 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. Yes, I knew it myself. I integrated a first 'hack' which is a wrapper around cppu::bootstrap, because I wanted to see if it works out. But now Kay says, that it's not that good to use, so I guess the algorithm (searching process) could be made in Python. The question with this now is: Do we integrate it into uno.py and code it all in pure Python, or should we integrate it into pyuno.cxx where the source is not visible to the user? > 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 ? bootstrap() does get the local component context at the beginning and then specifies some random pipe name passing the string to the XUnoUrlResolver. So if we code it in pure Python, then we could use the local component context as it is already loaded on importing the uno module (->no second context, no side effects). Thus coding it in pure Python (into uno.py) would make sense to me, especially because if the user has not got the office for some reason, he can change the code right in the python module 'uno' to whatever he wants to and he doesn't need to obtain the source code in order to modify pyuno.cxx. So rather than having something - that is said to be not 'perfect' - hard-wired into pyuno.cxx with no simple opportunity for the user to modify the function definition, I tend to have it transparent and available for direct code change, although performance would suffer a bit more, than if it would be implemented using the Python C API. -- Best Regards Christian Junker --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
