Lightweight IPC for scripting

Daniel Barlow writes:
> 
> As many people by now have the misfortune to know, one of my pet rants
> about Unix as a desktop OS is the lack of decent support for scripting
> applications.  

What  a  strange  idea,  given  emacs,  gimp,  autocad,  the  NeXTSTEP
Distributed Objects (re-implemented in GNUstep), guile and a google of
embedable  scripting languages  ranging from  Common-Lisp to  TCL thru
Scheme, and not counting classical unix "applications" like that email
programm I don't remember the name  right now, but also big CASE tools
that  are actually a  group of  tools wholly  scriptable with  bash or
whatever is your prefered scripting language...


> Some apps do CORBA, some apps listen on sockets, some
> apps reread their config file when sent certain signals, some apps you
> can start twice and the second instance will communicate its command
> line args to the first, and some apps (e.g. GNOME, KDE stuff) use some
> vast framework which handles it all in a
> you-shouldn't-care-about-the-internals way
> 
> None of them have seen pervasive uptake, which makes me feel better
> about inventing yet another. 

Decent  supportS for  scripting  application, there  is. Perhaps  what
you're missing is a common standard?

What  about just  defining an  API and  having a  bunch  of subclasses
implementing  it  over  the   existing  "protocols".   Some  of  these
protocols  are  "retrospective"  (CORBA,  NeXT/Apple  DO,  lisp  based
scripting languages to an extent.  Other are not: you need to read the
documentation (hint:  implement the AI  that will read it  an generate
the model needed to drive the program).

Pure X  applications may make heavy use  of the X way  to identify the
windows  and  their  widgets, but  I  would  bet  that in  most  other
toolkits,  there is  only one  X window  and every  button,  field and
subview inside it is entirely drawn and managed by the toolkit. Have a
look at GNUstep for example.  You won't go far trying to find a button
with X  primitive in a  GNUstep application running  in a X  window (a
GNUstep application could run also with different non-X backends).

So  to be  general, it  would be  better to  develo an  AI  that would
analyse the screen bitmap,  recognize the buttons, and other controls,
the data fields,  OCR and "see" them (hopefully we  can get 100% here,
since there's  not much noise,  only some anti-aliasing...),  and then
you could try to drive the mouse and click and drag around.

So, combining both AI, you will have your scripting environment, where
you'll be able to ask in high  level language what you want to do with
your programs, whatever their kind and their scripting possibilities.



Perhaps ambitious, but one can drean!

-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.