This is as days pass by, by Stuart Langridge

Hubert Figuere writes about scripting Linux desktop applications:

All the dirty work would be done within the scripting engine. It is the interface between the language and the IPC mechanism, and it implements the scripting protocol. The scripting interface will arbitrate, allowing to control several applications from one single script.

What he's describing there, broadly, is what the Windows Scripting Host does, I'd say. I don't think it should be JavaScript. Now, I'm a JavaScript guy, and I've written a book on it, so I like the language a lot. But it doesn't have any primitives for doing things like writing a file, which means you have to provide all that. It makes it awkward to write scripts in it on Windows, and it makes it awkward to write scripts in it in Mozilla, because essentially the fact that you're using JS is irrelevant; what you have to program to is the API you provide. The JavaScript gets lots of extra objects made available to it, and everyone has to learn about those objects, which is way harder than just learning JS itself. Writing a file using JavaScript and the Windows Scripting Host looks something like this:

var fso = new ActiveXObject("Scripting.FileSystemObject");
var fp = fso.CreateTextFile(savefile);
fp.WriteLine("Blah blah blah");
fp.Close();

Writing a file using JavaScript inside Mozilla (which uses XPCOM) looks something like this:

var file = Components.classes["@mozilla.org/file/local;1"]
		.createInstance(Components.interfaces.nsILocalFile);
	file.initWithPath( savefile );
	if ( file.exists() == false ) {
		alert( "Creating file... " );
		file.create( Components.interfaces.nsIFile.NORMAL_FILE_TYPE, 420 );
	}
	var outputStream = Components.classes["@mozilla.org/network/file-output-stream;1"]
		.createInstance( Components.interfaces.nsIFileOutputStream );
	outputStream.init( file, 0x04 | 0x08 | 0x20, 420, 0 );
	var output = document.getElementById('blog').value;
	var result = outputStream.write( output, output.length );
	outputStream.close();

To be honest with you, I think that the AppleScript approach is a better one than the MS COM/Mozilla XPCOM approach. In COM, each app exports an API, and you talk to that API. In AppleScript you talk to the app as if you're a user of it. Personally, I'd like to see someone bash on Dogtail (http://people.redhat.com/zcerza/dogtail/) until it's a generic scripting thing. The advantage you get with using Dogtail, which goes through the X accessibility APIs, is that apps do not have to provide a programming API explicitly. Every application on Mac OS, as I understand it, is automateable through AppleScript. Most applications on Windows are not programmatically controllable. Microsoft apps normally are, but third-party apps aren't. If you have to provide a separate programming API for your app then (a) that's extra work for the hackers, and (b) that's extra documentation required. Even more so than just using an app, an app's programming interface is useless without documentation, and documentation is one thing that the open source community does not do well. Let's take Dogtail, or something like it, and make it do the work for us. If Dogtail can do most of the stuff we need, then adding JavaScript bindings for it would be pretty easy by comparison.