Rick McGuire wrote:
> 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.
Ad regsitry settings: yes, this is vital for the language to be usable
as a WSH scripting language (WSE). I seem to remember that it was quite
difficult for the Object REXX to figure out the necessary registry
settings due to incomplete or outdated official documentation on MS side.

> 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.

The Object REXX support was mostlikely modelled after Microsoft's
implementations for VBScript and JScript (part of WSH which originally
got introduced with the MSIE). AFAIK all methods of the objects the
script host (MSIE, IIS/ASP, MS' Script) registered with the scripting
engine are made available as routines as well.

Hence, in ooRexx terms you can therefore do, e.g

    window~alert('this is an alert message')
      /* or instead */
    call alert 'this is an alert message'

> 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.
Whoever uses MSIE as a GUI or IIS/ASP kind of apps will be affected.

Also, whoever uses/employs WSF (Windows Script Files) and WSC (Windows
Script Components).

Maybe some of these slides may give a little bit of information and
nutshell examples:

    * http://wi.wu-wien.ac.at/rgf/wu/lehre/autowin/material/foils/AutoWin_2.pdf
    * http://wi.wu-wien.ac.at/rgf/wu/lehre/autowin/material/foils/AutoWin_3.pdf

> 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.
BSF4Rexx will eventually cover JSR-223, but I have been waiting for the
new implementation of the WSH stuff as that will probably create a
genuine ooRexx scripting framework that should be honored there.

As you know, I have served as an expert on the JSR-223 specification
group for a couple of years I recall that the spec lead from Sun liked
to sometimes to refer to the WSH implementation in the discussions.

> Ok, those are the things I've discovered so far.  I'm posting this
> largely to get the discussion started.
There is one point in particular, that I would like to see discussed:
how to deal with (incorporate) host objects into a Rexx script? This
should get attention and thorough discussion upfront.

The Windows philosophy just ignores any scoping rules and forces/pushes
host objects into the executing context of the script, overwriting AFAIK
any existing script variables and functions that happen to have the same
name by chance (have not tested it right now, but is currently more a
vague memory). Obviously the intention was to ease the script coder's
life by supplying (pushing) the host objects; one of the alternatives
would have otherwise been to explicitly incorporate those host objects
by some function.

In the JSR-223 case it is up to the script engine implementer how to
make the host defined objects available to the script.

In ooRexx one possible resolution (keeping the context of any script
intact) would be to have an environment entry named ".host" which allows
for referring to host-registered objects by name. Accessing ".host" may
trigger a lookup in some external host table and returning a reference
to registered host objects. So instead of having a magic "window"
variable accessible one would use ".host~window" instead, which also
documents the source of the object. [Of course, in order to allow for
backward compatibility in the Windows case one may need a configuration
option, that can be set by the programmer, allowing it to be set by
default to the Windows behaviour, if a WSH-related script.]

In any case it should be possible to enumerate all accessible host objects.

Just a few thoughts...


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

Reply via email to