[api-dev] Question ad creating and deploying components, implemented in (dispatchable) scritpting languages ...
Hi there, if this is not the right list, please advise. [This e-mail is directed at dev@api.openoffice.org and d...@openoffice.org, and the Reply-To-field set to d...@openoffice.org.] After peeking around the documentation (mainly developer's guide) currently one is able to create componenents in C++ and Java (and also in Python). The question: how would one create and implement UNO components in scripting languages that can be deployed via the OOo (Java-based) scripting framework (e.g. JavaScript/Rhino, BeanShell, but also ooRexx or other BSF-scripting languages)? Some of the questions that may be needed to be addressed would be: * How can one dynamically add IDL kind of type information to the registry, such that the new types become reflectable? * How can one register a component dynamically ? * How can one supply a service manager object to be used for instantiating instances? * How can one take advantage of helper classes (XWeak, XComponent) ? Are there any links/hints to postings, definitions, sketches of such a functionality? Is there some experimental implementation available somewhere (or is it even available already)? Short of that, how is the Python support implemented? Is there a documentation about the architecture and the UNO APIs it uses? What are/were the problems there, are there any shortcomings? --- Maybe to rephrase this question differently: I would like to come up with a solution for OOo disptachable scripting languages, in which script programmers have no need for the OOo SDK, if they wish to create UNO components in their scripting language of choice. (The necessary complexity involved in creating UNO components, should be reduced to an absolute minimum, where this minimum should be to have no need for installing the OOo SDK.) TIA, ---rony
Re: [api-dev] Question ad creating and deploying components, implemented in (dispatchable) scritpting languages ...
Hi Rony, see some comments inline On 1/27/10 4:50 PM, Rony G. Flatscher wrote: Hi there, if this is not the right list, please advise. [This e-mail is directed at dev@api.openoffice.org and d...@openoffice.org, and the Reply-To-field set to d...@openoffice.org.] After peeking around the documentation (mainly developer's guide) currently one is able to create componenents in C++ and Java (and also in Python). C++, Java and Python we have real language bindings, for all other we have bridges only. That is the main difference. The question: how would one create and implement UNO components in scripting languages that can be deployed via the OOo (Java-based) scripting framework (e.g. JavaScript/Rhino, BeanShell, but also ooRexx or other BSF-scripting languages)? Some of the questions that may be needed to be addressed would be: * How can one dynamically add IDL kind of type information to the registry, such that the new types become reflectable? do we want this because we wouldn't have any documentation for this new types. Don't get me wrong it's just a question, we also have thought in this direction in the past as well. * How can one register a component dynamically ? that is already possible i think. You add an appropriate factory implementation for a new service implementation. * How can one supply a service manager object to be used for instantiating instances? that would be one of the more interesting parts. All language bindings provide some kind of bootstrap mechanism to get started, prepare a connection etc. That would be necessary * How can one take advantage of helper classes (XWeak, XComponent) ? you have to provide similar helper for the scripting language of choice Are there any links/hints to postings, definitions, sketches of such a functionality? Is there some experimental implementation available somewhere (or is it even available already)? i don't think so, maybe you can take a look in the implementation of the Python binding Short of that, how is the Python support implemented? Is there a documentation about the architecture and the UNO APIs it uses? What are/were the problems there, are there any shortcomings? as far as i know it is not really documented, no chapter in the DevGuide etc. And i would say it is still not really maintained. --- Maybe to rephrase this question differently: I would like to come up with a solution for OOo disptachable scripting languages, in which script programmers have no need for the OOo SDK, if they wish to create UNO components in their scripting language of choice. (The necessary complexity involved in creating UNO components, should be reduced to an absolute minimum, where this minimum should be to have no need for installing the OOo SDK.) i agree to the statement The necessary complexity involved in creating UNO components, should be reduced to an absolute minimum but the SDK doesn't provide too much i would say. New APIs have to be defined in IDL - so at least idlc is necessary. The other tools can be useful for C++ and Java. The header files for C++. What else is there, the IDL reference, some docu and examples. Ok for IDL we can think of an integrated idl compiler ... In general i like the idea but i would focus more on better tooling around scripting languages. I still have in mind to provide a better integration for scripting languages in NB. Juergen - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Question ad creating and deploying components, implemented in (dispatchable) scritpting languages ...
Hi Jürgen, see some comments inline thank you very much! The question: how would one create and implement UNO components in scripting languages that can be deployed via the OOo (Java-based) scripting framework (e.g. JavaScript/Rhino, BeanShell, but also ooRexx or other BSF-scripting languages)? Some of the questions that may be needed to be addressed would be: * How can one dynamically add IDL kind of type information to the registry, such that the new types become reflectable? do we want this because we wouldn't have any documentation for this new types. Don't get me wrong it's just a question, we also have thought in this direction in the past as well. Well, I was thinking along the lines that while installing a component a script could be fired that would create the appropriate entries in the registry. Con: could be quite complex and error-prone (maybe one could define the IDL in XML and have unopkg process it and - let? - create the appropriate rdb entries). But I have no clues what I am talking about (w.r.t. complexities and risks in this delicate area). * How can one register a component dynamically ? that is already possible i think. You add an appropriate factory implementation for a new service implementation. * How can one supply a service manager object to be used for instantiating instances? that would be one of the more interesting parts. All language bindings provide some kind of bootstrap mechanism to get started, prepare a connection etc. That would be necessary Would it be possible/conceivable that the above two needed functionalities could be also defined in a XML configuration file, defining the respective dispatch URIs? This way a script engine implementation could define the dispatch for running the respective scripts that implement __getServiceFactory (String, XMultServiceFactory, XRegistryKey) and __writeRegistryServiceInfo(XRegistryKey). * How can one take advantage of helper classes (XWeak, XComponent) ? you have to provide similar helper for the scripting language of choice O.K. (this would be fairly straight-forward, some BSF/javax.script scripting languages could even take advantage of the Java helper classes). ... cut ... --- Maybe to rephrase this question differently: I would like to come up with a solution for OOo disptachable scripting languages, in which script programmers have no need for the OOo SDK, if they wish to create UNO components in their scripting language of choice. (The necessary complexity involved in creating UNO components, should be reduced to an absolute minimum, where this minimum should be to have no need for installing the OOo SDK.) i agree to the statement The necessary complexity involved in creating UNO components, should be reduced to an absolute minimum but the SDK doesn't provide too much i would say. New APIs have to be defined in IDL - so at least idlc is necessary. The other tools can be useful for C++ and Java. The header files for C++. What else is there, the IDL reference, some docu and examples. Ok for IDL we can think of an integrated idl compiler ... In general i like the idea but i would focus more on better tooling around scripting languages. I still have in mind to provide a better integration for scripting languages in NB. If you (or anyone else) is going to enhance the scripting language support of OOo, may I suggest to use the javax.script framework, which is available in a pre-Java6-implementation from Apache under the project name BSF *3.0* (this is an implementation of JSR-223 specs, which got implmented in Java 6 in the package javax.script): http://jakarta.apache.org/bsf? This would allow OOo to make all JSR-223-scripting languages available for OOo (but of course the UI would need to be adjusted as the Tools-Macro branch would have to cater for a flexible number of scripting languages that may be available). To get an overview of how to use it (how complex it is), cf. e.g. http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/. Enumerating all available scripting languages is as easy as e.g. http://javacook.darwinsys.com/new_recipes/26callingall.jsp, which also demonstrates how easy it is to invoke ECMAScript/JavaScript/Rhino from Java. A (not complete) list of available JSR-223-scripting languages can be found here: https://scripting.dev.java.net/. Using BSF 3.0 would allow OOo, which Java baseline is 1.5, to fully exploit/employ the javax.script package, as BSF 3.0 can be deployed from Java 1.4 on. (On Java 6 and higher the respective javax.script implementations would take over, of course.) Regards, ---rony P.S.: Just a side-note: for the current ooRexx support I am using BSF 2.4 which is not compatible with BSF 3.0, but follows the same principles: defining a Java framework to ease deploying scripts in non-Java-languages for Java programmers. (Due to my BSF 2.x experiences I was serving as an expert on the JSR-223 to
