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 help define the Java scripting framework. Then once the JSR-223 specs were finalized, a group of people at ASF implemented the specs as well under the name "BSF 3.0"; this opensource implementation of JSR-223 can be deployed starting with Java 1.4, which still is widely installed/used in companies, the license is of course the Apache License version 2.0, which could be used for OOo, if I am not mistaken.)
