[alicebot-archcomm] AIML architecture vs. application architecture

[Jon Baer]

I have some initial viewpoints here which I hope come across.  And I hope I
make all the points below so that I don't leave anything out which is coming
across my mind.  First is the fact that Program D to begin with was an
unfinished product that really came from my head and was a major hack over a
span of a few weeks leading to Dany, leading back to Program D but I want to
say that there should be kudos to Pedro, Thomas, Kim, et al for "cleaning up
Jon Baer's mess" and if likewise I had the energy or desire to first design
UML charts and then work on the server, lol, Id probably turn back the clock
and do so.

The goal from the beginning was *not* to create something new but rather to
repackage Program B into a tightly knit package/architecture/whatever.
While working on it and the massive blow of not having a laptop for a while
I decided to rethink things and started the "TinyAlice" stuff, in which this
goes along with the whole Foundation blowout during the "early days".

So anyways, it was never an abondonment on my part to say Program D will
never work large scale, it was just a move to reimplement everything.  The
point being I am very grateful to those who stuck by it and want to continue
with it and really make it into something.

My second point is as you list something below (that being <substitute>)
what I think you have to understand is that just being you *see* and XML tag
somewhere or an opinion that is given out on the list you can not
automatically assume it is meant for AIML somewhere.  It may have been
different if people didn't configure their stuff using XML but tags are tags
and there could be a million different ways to configure a server in which
the XML will run into *looking* like its meant to be for AIML but it's not.
Likewise your point of something being abstract is very difficult because
there are also parts which inter-relate to how the AIML is going to work.

The one big thing I think that is missing is probably a step-by-step
procedure chart on what exactly *should* happen when A) the server starts -
what things can or should be configurable, like substitutions and B) the
user sends and input, things like that are clearly non-implementational
specific and would help alot and probably just leads to ur point of the
architecture of Program D, which was never defined to begin with.

My third point and probably most important is that one thing Im very
discouraged by is probably the drawbacks of very difficult implementing of
certain things that can come up like XLink/XPointer and Javascript.  I
personally find them all to be essentials of some type, but the way they
would float about in AIML would not make things very likely that they be
included as being a normal thing.  Just to give an example I implemented
this:

<category>
  <pattern>GET NODE ONE</pattern>
  <template>
   <link href="file.xml#/root/node1/text()" alt="Hi!"/>
  </template>
 </category>

This is an immediate form of XML Linking from http://www.w3c.org/XML/Linking
using Jaxen XPath.  Now this probably would be kinda hard to implement in
C/C++ or whatever (remember its just experimentation) but some type of
linkage is a big plus for some projects.  But the fact that it can't be
drawn into other implementations like <javascript> kinda hinders on the next
step of things I think.  Im not really going to complain because quite
honestly Im quite please with how the line of AIML and Interpreter have
been.  Im kinda getting a kick out of being unemployed, broke, and building
interpreters all day, but I am kinda sticking with AIML in its current form
and trying to find balance.  I think through it all that's the key for
success in this project is trying to find the balance between the AIML and
the power of the interpreter.  Program D is obviously *not* going to be the
only interpreter, but I would side with you on saying that maybe there
should be some type of rules or outline for ones that follow.  For example:

An AIML Interpreter *MUST* provide a method for substituting input
externally (The Alicebot Substitution Format, ASF).
An AIML Interpreter *MUST* provide a common logging method (The Alicebot
Logging Format, ALF)

Etc, etc, etc.  Even just splitting those tasks among people can provide a
more clearer picture of the parts beyond just AIML.

- Jon

Noel Bush wrote:

> 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