Ok, since I wasn't tied down with new bug reports this morning, I thought I'd start looking at the orxscript stuff again and start putting together a plan for what we're going to do with this. This is just sort of a random collection of thoughts right now, but I thought I'd put some of these things down in writing to kickstart the discussion.
1) State of the code. The 3.2.0 was a serious hack, based on a bunch of really strange private APIs into the interpreter that broke a lot of rules for how APIs needed to be written. All of the private APIs have been removed from 4.0, and I have no intention of adding anything resembling what they did back into the API set. In the 4.0 trunk, there are the results of my original attempt at making the conversion to using the new API set, but I'm now of the opinion that this really needs to be junked and really started over from scratch. Structurally, I'd like to see this implemented by defining an ooRexx ScriptContext class that would be capable handling the different scripting interactions. Done correctly, one should be able to create and manage a scripting environment entirely from ooRexx (not the Windows one, obviously, but you could write an app in ooRexx that coule be able to embed "scripts" in the same sense.). Such a class, for example, would be real handy in mod_rexx. The initial requirements for this script class will be driven by the requirements of the Windows scripting host, which I have not found any good documentation yet on how it works. The individual COM interface classes are documented, but I've not found any information on how things work, the order of events, how the different classes should interact, etc. I suspect that my best bet on figure this out would be to spend a bunch of time in the debugger tracing how the 3.2.0 works. Unfortunately, the scripting support requires an installed version which will seriously mess up my normal development machine, so I'll probably see if I can setup a second machine just for that purpose. 2) Compatibility. I'm not sure what to do here. I spent some time reading the 3.2.0 WSH docs this morning, and I found a few things quite appalling. The base scripting support just barely works because of how variables are managed between the different script fragments. We have a couple of bugs open against those characteristics already, and just fixing those bugs will result in come differences in behavior. The .wsc support is absolutely horrible. COM object equivalents are created using the same lame scripting support described above, with methods defined as ::ROUTINES rather than real methods. During the registration process, the exported "object" has to hand construct the typelib information using OLEObject. This is the area I'd most like to replace, and would do so by allowing any arbitrary ooRexx class to be exported as a com object and the properties mapped to the appropriate ooRexx ::attribute methods. I don't know yet if it would be possible to implement the ideal solution while maintaining the old style of definition. I have no sense on how many people are actually using the WSH capabilities. Given the state of the code, I would have expected there to be a larger number of bug reports or RFEs against this component if people were using it for real things. 3) JSR-223. The Jave community process has a specification entitled "Scripting for the Java Platform". This defines the Java APIs for two-way script interactions between Java and non-Java languages. I have an additional goal that the scripting class I wish to create to reimplement the WSH code will also be sufficient for implementing a JSR 223 scripting adapter. I've not had a chance to read this spec in much detail yet, so this is a work in progress. It does seem to be more rigorously documented than the Windows support appears to be. Ok, those are the things I've discovered so far. I'm posting this largely to get the discussion started. Rick ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
