[alicebot-archcomm] AIML architecture vs. application architecture

[Conan Callen]

Great work!

UML? Check out www.auml.org

Conan

> I see a lot of independent tasks from the main
> thread of abstract AIML architecture (model).
> I hope you will see my point in the attachment.
>
> Eugene
>
> ----- Original Message -----
> From: "Noel Bush" <noel@alicebot.org>
> To: <alicebot-archcomm@list.alicebot.org>
> Sent: Monday, November 12, 2001 3:43 AM
> Subject: [alicebot-archcomm] AIML architecture vs. application architecture
>
>
> > 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
> >
> > _______________________________________________
> > alicebot-archcomm mailing list
> > alicebot-archcomm@list.alicebot.org
> > http://list.alicebot.org/mailman/listinfo.cgi/alicebot-archcomm
>
>