My first thought is that Eclipse Monkey needs to support the Jobs API. Running scripts exclusively from the UI Thread is not just a bad idea, its really a showstopper. I defined a metadata tag called 'Job' that supports running the script from within one of three modes:
1. The UIJob which runs in the UI Thread.
2. The WorkspaceJob which runs the script from within the WorkspaceJob class that can prevent other Eclipse Jobs from impacting the workspace at the same time.
3. The default Job which spawns an ordinary Eclipse Job to run the script.
My second thought is that the decision needs to be made whether Eclipse Monkey is to be exclusively focused on a particular language ( i.e. _javascript_ ) or whether the goal is to try and throw open the gates to allowing as many languages that can be used on the JVM to be used in Eclipse Monkey. I understand the concern with _javascript_ in particular, I would like to check to see if there is a way to accomodate making the language 'feel right.' I don't see a problem with customizing some DOMs to facilitate development in another language, afterall it's all java byte-code in the end.
So my perference would be to allow as many languages as possible and I would volunteer the metadata tag 'Language' implementation in Groovy Monkey to facilitate that end. I think the Apache Beanscripting Framework is an excellent candidate since almost all JVM based scripting language implementations have a BeanScriptingEngine implementation that could be exercised.
One other thought, in Groovy Monkey I implemented the 'Include' and 'Include-Bundle' metadata tags that allow the script writer to directly include directories/jars in the workspace and active bundles in the workbench to the classpath of the script. I know the implementation works in Groovy, Beanshell and JRuby, the BeanScriptingEngine in Rhino failed, but since I revamped it recently I haven't tried it again.
I think that the Include and Include-Bundle features are very useful, but they can be viewed as a violation of the everything as DOM paradigm. Now for some that might not be a bad thing, but given the inherent overhead work in generating a plugin and to try to load it into the current workbench instance, I think that the shortcut is a valuable thing. I have an example highlighted on my blog:
http://iacobus.blogspot.com/ and I have a specific posting dealing with Rapid Prototyping of DOM plugins:
http://iacobus.blogspot.com/2006/08/groovy-monkey-eclipse-icons-script-pt_08.html
I think the issue of making a scripting language feel more at home in Eclipse Monkey is one that requires further study. Paul where in the cvs repository are the examples we discussed during the teleconference? At work the firewall only allows me access to the cvs repository through the web. This brings up one other small issue, could we transition the code over to a subversion repository instead?
I do also think that have a good default set of included DOMs for people to use would be a very good idea. A console DOM is beyond necessary in my view and I would love to add ones that allow the script to create some useful Dialogs easily would be great.
--
James E. Ervin
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein
