[alicebot-archcomm] AIML architecture vs. application architecture

[Noel Bush]

I see your point in the attachment, and it looks as though several of us
agree that a broad outline of use cases is very useful for directing our
work.

I tend to agree that the only practical way to proceed with something
like this is to work on it collaboratively using some kind of web
technology.  I am inclined to set up a "wiki" that would allow us to do
this, although I am not sure if that is the right mechanism.  Does
anybody have experiences with this?

One rather obvious use of this chart (not the only use) is as a kind of
"help me" framework.  The word "To" at the start of each bullet point
can become "How do I", and ideally we should be able to supply a link to
some documentation on each point.  A very useful exercise would be to
try this together, and find out which of the use cases already have some
practical implementation, and which exist as "recommendations" or
"possibilities" only.

This is definitely very helpful as a framework for identifying many of
the major issues that will confront corporate decision-makers when they
think about using AIML.

-----Original Message-----
From: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org] On Behalf Of Eugene
Lebedev
Sent: Tuesday, November 13, 2001 1:13 AM
To: alicebot-archcomm@list.alicebot.org
Subject: Re: [alicebot-archcomm] AIML architecture vs. application
architecture


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