Subject: (fwd) Re: Scripting with Visual Basic Clone
From: Dirk-Jan C . Binnema (bulkmail@dds.nl)
Date: Fri Jun 30 2000 - 04:55:00 CDT
Hi all,
Recently, I sent the message below to the bonobo mailing list, and I
think it's very relevant to the discussion. Basically, it's about
having well-defined interfaces for scripting language and application,
so people can connect any scripting language to your app.
The challenge for Abiword is it's XP capabilities - the mechanism
chosen should be portable. This makes using Bonobo quite hard I
guess...
However, on the Win32 platform you can simply use the available
ActiveScript* approach. Other platforms will be harder.
One of the strengths of the approach is the loose coupling between
language and application. However, this is also a weakness -- it
requires the language you chose to write this little Abiword macro in
also to be available on any platform somebody wants to use that macro...
---------------------------------------------------------------------
In the plan for Bonobo world domination, scripting is
pretty important, I guess (where 'scripting' means programming using
some extension language, within the context of some program, such as
Emacs elisp or Gimp ScriptFu).
It seems that scripting will used in more and more programs, ie. gb in
gnumeric and (perhaps) some yet-to-be-decided language in Abiword. It
seems though that the same problem (embedding language X in
application Y) is solved over and over again.
What would be nicer to have one approach to be able to embed any
language in any application. One such approach is Guile -- it's very
easy to embed the Guile interpreter in your application. Now, to
support your favorite scripting language, *all* you have to do is write
a translator Perl->Scheme, Python->Scheme etc. However, this is
non-trivial (to say the least). There have been some attempts at
translators (tcl, javascript, ctax), but I don't think these are
'production quality'. In my o-so-humble opinion, the Guile-approach is
not going to work. (This is _not_ to say Guile is useless - Guile is a
very nice embeddable Scheme interpreter for which the Guile developers
deserve a lot of admiration; it's just the translators-part that's not
going to work, IMHO).
So what other approaches exist? What about defining some
idl-interfaces for scripting languages and their host application?
This is approach chosen by the MS ActiveScript mechanism. The
embeddable language will do stuff like (*very* simplified example):
interface EmbeddableLanguage {
void initialize ( in Host host );
void run ( in string script );
};
interface Host {
void on_error ( in Error error );
};
Now, the interesting thing is of course how to get application
specific stuff in your scripting environment, e.g. your 'Sheet'-object.
To do that, we can add another method to EmbeddableLanguage:
void add_object ( in Unknown unk, in string known_as );
and you can offer a reference to your Sheet, with some friendly name
"sheet" to your scripting environment, in which you could then write
sheet.do_something_useful(1,2,3)
The beauty of the mechanism is the loose binding between host app and
scripting language. As long as both implement the interfaces, you can
choose any language/app combination. In my previous job, I wrote a
WinNT mail-router in C++ that implemented the Host interfaces, and was
able to script it in VBScript, JavaScript, Perl, Python and even
Haskell! While MS developed the ActiveScripting stuff, unfortunately
they don't use it for Office - in Office VBA seems hardcoded.
In the Unix environment, probably Perl and Python are the easiest to
write EmbeddableLanguage glue for, as they have working
CORBA-bindings. Bash will be a little harder ;-)
On the Host side, an application must be able to serve it's 'object
model' as a Bonobo (CORBA) object. This may not be trivial for all
apps.
----------------------------------------------------------------------
--Dirk-Jan.
+--------------------------------------------------+
Dirk-Jan C. Binnema <djcb@dds.nl>
http://www.casema.net/~devnull
--------------------------------------------------
PGP/GPG fingerprint:
BB49 41D7 053D E5F1 F333 586E C530 CBC3 4352 A39F
+--------------------------------------------------+
This archive was generated by hypermail 2b25 : Fri Jun 30 2000 - 04:47:33 CDT