[alicebot-archcomm] Another suggestion for AIML architecture

[Jonathan Roewen]

> There are several versions of the AIML engine, each specialized in an
> operating environment, that is, a language.  We have Program E which
prefers
> PHP.  We have Program V which uses Perl.  Of course there is the Program D
> which is Java.  Program N written in C++ (or Program J if you prefer.)
And
> Program P for Pascal.  Program Z for Lisp.
>
> Each of these (except J and possibly P) have extended the AIML standard to
> include the language best for their environment.  Starting with D we have
> <javascript>.  In E we get <php>.  In V we get <perl>.  In N we get
> <script>.  Does Z have <lisp>? And in each we have <system> which probably
> is different for all.

I personally believe that the <javascript> tag would not be overwhelming
difficult to become a part of the spec, if at most an optional part. Whilst
other interpreters do supply these alternative tags, it is due to the
ability to process the contents in the same language as the language to
build the interpreter. As for ProgramD .. although it is written in Java ..
JavaScript is not Java.

JavaScript already has a few implementations on just about every platform,
in a variety of languages. Providing server-side javascript capabilities is
a possibility for most interpreters.

Of course, there is the alternative track of taking away all these script
tags, and sticking with the very abstract <system> tag as the only means to
provide some sort of scripting support to AIML on the server-side. With the
system tag, you can use sql such as with the command-line mysql client, call
a specific script interpreter, such as python or perl, for example. And then
you can access OS-specific behaviour. There is also the possibility of
launching applications.

> I propose that we create a standard tag for extensions to the language
that
> is best for the platform.  In html it is called <script> and it adapts to
> what the browser can handle by an attribute.  I wouldn't really want to
> confuse the html with aiml, so I suggest we improve the <system> tag
> (although I am surely open for debate here since html and aiml should work
> together and share functions like formatting - including scripting.)
> Instead of <perl> we could write <system language="perl">.  Instead of
<php>
> we could write <system language="php">.  This would allow the aiml
standard
> to have a fixed specification for any future API or languages that might
> benefit the aiml engine.  A <system> without the language attribute would
> operate either as the preferred language of the engine or as the existing
> <system> does now.  Actually the existing definition for <system> means no
> single implementation of <system> acts as it does now, since by the
standard
> it is platform dependent.  Which is exactly what the new additional tags
> seem to be doing and want to do.  They are enhancements for the platform
in
> which they run.

That is a possibility, however, it may be desirable to create some sort of
interface usable within a particular scripted environment for accessing
certain parts of the interpreter.

For instance, in J-Alice, we have a global 'bot' object in javascript that
allows retrieval of <star> <thatstar> etc, and <get> and also allows you to
set a variable as well. There are a couple others as well I think.

My point is .. this interface is only valid within the context of the
javascript (it allows such things as using set and get in a loop, rather
than having it replaced before the script is executed -- which would happen
if you used the actual AIML tags themselves in a non-cdata section).

Actually, no, this is a good idea.

The only problem is standardization of the <system> tag itself. There are a
number of issues to consider: whether <system> should start a new process
and run asynchronously or synchronously. If async, do we allow output from
the new process -- I would assume no here. How would you specify if it is to
be synchronous or asynchronous .. if both are to be allowed. For example,
launching an application should be asychronous. Getting a directory listing,
however, should be synchronous, as we need to capture the output of the
command.

Then there are multi-user issues. Does calling a synchronous command that
takes a long time (possibly infinite), does the server block all other
requests until this process has finished? Can a different user still
interact with the bot?

Server-side scripting is a complex issue .. providing a single abstract
interface, the <system> tag is just scratching the surface ;-)

Jon =)

PS: This has come up before .. originally as a universal <script> tag with a
similar attribute to what you have ;-)