-> > I think Tcl (or, rather, "single language support")
-> > is one of the big things holding AOLserver back.
->
-> I thought the same thing two years ago. I'm now convinced Tcl was and is
-> still the right choice for the core scripting language, and believe it
-> should remain the core language. It simply wouldn't be AOLserver
-> otherwise.
For what it's worth, I won't argue ;). Tcl is a perfectly good language
for configuration -- I don't see how Python, or Perl, or <insert language
here> could do anything better -- and it's easy to learn.
I just happen to think in Python <shrug>.
-> But you are correct in that we need to support other languages. That
-> could be done with modules, and maybe some means of binding to internal
-> Tcl data structures at the C level could be found so that, say, a java
-> module can exchange data *directly* with Tcl internally -- maybe some
-> kind of "standard" binary format for data interchange (Binary XML?).
-> Maybe a capability that is similar to comm and db drivers -- a way to
-> write "language drivers" that register themselves with the core server.
-> That's definitely an area for exploration.
PyWX allows you to do and access everything Tcl-ish from Python, and vice
versa. I'm sure this is possible with PHP, too. Java will be difficult,
unless GCJ is picked ;). Perl would be tricky, but a few years ago, when
we were just starting to get serious about PyWX, someone mentioned that
they'd started a Perl integration project for AOLserver. I'd be interested
in taking a look at it as a possible winter break project, if it's still
around.
I haven't found that data exchange is a big issue: Mike Haggerty used SWIG
to wrap the entire internal C API for Python, and the latest version of
SWIG seems to output for Perl, Guile, Scheme, Ruby, Java (???), and PHP as
well. This might be worth looking into, come to think of it...
--titus
P.S. Links:
PyWX - http://pywx.idyll.org/
SWIG - http://www.swig.org/
