[alicebot-archcomm] AIML architecture vs. application architecture

[Noel Bush]

Even though this may be opening up a can of worms, I feel obligated to
mention that I notice a positive development: a clearer distinction
between two tasks:

1) architecture of an abstract AIML interpreter
2) architecture of Program D

Some of our disputes in the past may be seen as having missed this
distinction, so that at times we were talking about *both* the Program D
architecture and the architecture of an abstract AIML interpreter.  For
instance, the question of "how to set things at startup" looks like an
application architecture question, not (necessarily) an AIML
architecture question.  On the other hand, the question of "how <random>
should behave" is clearly an AIML architecture question.

I mention this because I've recently been doing some cleanup,
optimization and enhancement work on Program D, and I've found it much
easier than in the past to see this distinction.  The AIML spec WD does
still stipulate a few things which perhaps impinge too much on
application architecture, but for the most part it sticks with AIML
interpreter architecture.

This gives me the feeling (perhaps mistaken) of liberty to introduce
changes in how Program D is configured, so long as they do not change
the runtime interpretation of AIML.  For instance, in looking at how to
make Program D support externalized substitutions, it seems clear that
these can be specified in an XML file using a <substitute> tag (a la
TinyAlice) without causing any controversy, since <substitute> makes no
claims on being an AIML element.  Program D could just as well implement
this using a non-XML format (unlikely) or by requesting substitution
information at a command-line on startup (obviously silly) -- the point
is that nothing is changed about the behavior of the AIML interpreter.

I hasten to add that all such changes are being reviewed continuously by
Kim Sullivan and Tom Ringate, who have distinguished themselves as
high-profile, energetic advocates of usability with respect to both
Program D and AIML in general.  The present work is on an incremental
version "4.1.3" which will include not only cleanup and optimization
fixes grounded on Tom's & Pedro's AIML compliance work, but also bug
fixes, some forward-looking architectural improvements, as well as some
functional enhancements (user authentication option, external
substitution specification).  As in most user community-driven
scenarios, it is expected that the smaller advocacy group (in this case,
Kim and Tom) will be widened to a larger group with either a beta
release (something we haven't done yet), or just a "point release" (less
than ideal, but it works), from which additional user feedback will be
gathered and factored into future releases.

We're making heavy use of CVS, so all changes are traceable, reversible,
documented, etc.

Any comments are welcome.  If somebody feels like this is not the way to
go -- that small changes to the reference implementation also need to go
through committee -- please do say so.  In such a case I think we need
to work up an actual Program D spec, which I personally feel will
introduce an unnecessary delay.

Noel