[alicebot-archcomm] Another suggestion for AIML architecture

[Gary Dubuque]

As far as I know <javascript> is already part of the standard for AIML
version 1.01.  I could be wrong.  And the definition I've recently heard for
<system> is to run programs on the host, that is to shell out the processing
to other executables.  As such, I withdraw my suggestion to name a common
scripting tag as <shell>.

I totally agree with you about a object model for accessing the bot's
processing and variables.  This seems larger than just collecting all the
variations of exits to scripting into a common tag.  It seems natural to
define, for such a tag, the circumstances under which it is used.  It would
have a major impact on implementations of AIML engines.  It should be
prototyped first before an informed discussion can be entertained.

Without causing to much furor in the overwhelming task of standardizing
internal processes of bot engines, I still would like a nice foothold to
differentiate system executions from system scripting in some generic sense
instead of language specific.  The <javascript> is equal to <perl> or <php>
and maybe we should embrace those tags in the standard as well.  Maybe <ss>
for serverside scripting is a possible shortcut to allow outside languages
to extended AIML processing.  Either way, I foresee only more possible
languages being added to the mix unless a graceful way of including these
extensions is declared.

Searching,
  Gary Dubuque
  Have AIML, need more fiber

-----Original Message-----
From: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]On Behalf Of Jonathan
Roewen
Sent: Saturday, March 01, 2003 1:41 AM
To: alicebot-archcomm@list.alicebot.org
Subject: Re: [alicebot-archcomm] Another suggestion for AIML
architecture




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

_______________________________________________
alicebot-archcomm mailing list
alicebot-archcomm@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-archcomm