Desktop scripting
by hub, Sunday 16 April 2006 at 18:20 :: Gnome :: #397 :: rss
I was thinking the other day about desktop application scripting. Scripting the desktop is basically high-level application programming, controlling third party applications. Real world examples include AppleScript on MacOS X and whatever MS Windows have. Also GreaseMonkey in Mozilla is a good example of internal application scripting.
How I think this should be implemented.
First: security. Security is the first major concern that should be a very strong requirement. Don't let security issues plague that, we have seen what it does on other operating system.
Second: it should be universal provided that the application provides the necessary hooks. And that universality should be cross desktop.
Third: it should be language independent with a sane default. And for that I'm thinking JavaScript. Why JavaScript? Because it is know by a lot of end user, as it is being used for webdesign, and some other world application like Photoshop use it as a base scripting engine. At least it make more sense by default than say Python or Perl. That language independence would also provide a way to implement said Python and Perl if desired. The idea of using JavaScript came from an article by Philip Greenspun on how to automate preparation of images for the web, which give a practical quick insight of what can be achieved inside an application. Note that scripting inside and scripting outside are 2 different things, but all you can do from outside could be done from inside.
But let's talk about the details:
There is a work to be done architecture-wise to achieve this properly. First let's not make the mistakes of previous implementations. For what I know, Apple initial implementation os AppleScript in System 7.1, in fact of OSA (Open Scripting Architecture) had 2 big flaws: it was complex to implement API-wise, and it was slow as hell.
Here is the architecture I think of, largely inspired by Apple's (designed 15 years ago):
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. The IPC mechanism could be DBus, DCOP or whatever suitable. And ORB might do it too. In fact the only required to be unique mechanism would be the way for the application to register itself with the scripting interface. Converging to a unique IPC mechanism would be prefered, but the cross-desktop nature of the interface might not give the choice.
What do people think about it?
Comments
Sunday 16 April 2006 20:25, by Yan Morin :: site :: #
Sunday 16 April 2006 20:30, by Robert :: #
Sunday 16 April 2006 21:14, by Dan :: site :: #
Sunday 16 April 2006 21:29, by John Nilsson :: #
Sunday 16 April 2006 21:44, by Stuart Langridge :: site :: #
Sunday 16 April 2006 22:10, by Lews Therin :: #
Sunday 16 April 2006 22:24, by Goran Rakic :: site :: #
Monday 17 April 2006 01:31, by Bill :: #
Monday 17 April 2006 03:12, by AM :: site :: #
Monday 17 April 2006 05:50, by Ingo :: #
Monday 17 April 2006 06:13, by str() :: #
Monday 17 April 2006 09:19, by Bruce :: site :: #
Monday 17 April 2006 19:08, by fsniper :: site :: #
Monday 17 April 2006 22:35, by George Dekavalas :: #
Wednesday 19 April 2006 03:37, by benoit :: site :: #
Friday 28 April 2006 19:01, by Mynator :: #
Friday 28 April 2006 19:08, by Mynator :: #
Saturday 29 April 2006 16:44, by has :: site :: #
Friday 26 May 2006 06:50, by MikeC :: #
Thursday 1 June 2006 15:03, by Stefan :: #
Friday 14 September 2007 21:51, by i386 :: site :: #
Post a comment
Comments are closed.