What we should do is build an API - but make sure that we build an
API that can be easily accessed by scripting language toolkits. The API
should only know that another program/process communicates with it
(two-way) via the API. Whether that other process/ program is a script
interpreter or custom code should be irrelevent. It would be nice if
scripting languages are kept in mind, so we should be passing strings
rather than pointers or whatever where possible, nice high level data. Also
reasonably high level commands.
If given a decent API easily accessible from C (or high level
language of your choice), it would not be very difficult to create
extensions/ libraries for most common scripting languages. For example Tcl
on Unix systems includes the ability to add new commands via C code. Mac
users could easily create an application that accepts Apple events, and
calls appropriate C bindings, allowing Applescript/ OSA scripting. If we
actually choose a scripting language, most people will probably be upset at
the choice, and it will not necessarily interact well wit existing
scripting systems, but with an API we can implement scripting to our hearts
content.
Cheers
David Cake