[alicebot-archcomm] AIML architecture vs. application architecture

[Eugene Lebedev]

Thanks. It's really nothing special, just
regular actor-goal table. It will be great
to get some comments from other members.
I'm sure that this table is not completed yet.

UML will be nice if we want to create
fully dressed use case. I would prefer
to go in this direction rather than discuss some
small separate issues. And then it will be
quite simple and logical to parallel the job.

And we will have some formal base for
discussion of currently hot issues (e.g. components,
context, security)

How about an idea to create section on the
web site "AIML Platform Use Cases"?

Eugene

----- Original Message -----
From: "Conan Callen" <ccallen@windowpane.com>
To: "Eugene Lebedev" <maineugene@yahoo.com>
Cc: <alicebot-archcomm@list.alicebot.org>
Sent: Monday, November 12, 2001 4:54 PM
Subject: Re: [alicebot-archcomm] AIML architecture vs. application
architecture


> 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
> >
> >


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com