[alicebot-archcomm] Another suggestion for AIML architecture

[Gary Dubuque]

Very good point.  This started as a murky issue.  It should be brought to
the light of day to attain a defendable posture.

AIML can't be exchanged gracefully without the path for degradation in
astire environments.  AIML per se is not designed to be a front-end to
back-end database processing or calculating and/or logic crunching machines.
It is just being used in that manner because it is so powerful while still
being so simple.

Lets remove <javascript> and <system>.  The only one we could possibly
depend upon is <javascript> but it doesn't have a consistent object model to
script.  On the other hand, standards like HTML do have a document model.

I wonder if these two should be degraded to informal specifications until
(or if) they can be properly defined for AIML.

Cheerfully,
  Gary Dubuque
  a wanderer with AIML spirit

-----Original Message-----
From: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]On Behalf Of Sandro
Golinelli
Sent: Monday, March 03, 2003 3:43 PM
To: alicebot-archcomm@list.alicebot.org
Subject: RE: [alicebot-archcomm] Another suggestion for AIML
architecture


At 10.07 02/03/2003 -0800, you wrote:
>As far as I know <javascript> is already part of the standard for AIML
>version 1.01.


in the AIML specs, point 1.1 (origin and goals) says, among other things,
the design goals of AIML shall not incorporate dependencies upon any other
language.

im i wrong to say that javascript scripts inside aiml are dependency upon
another language?

in facts, the specs says (point 7.8 external processor) that these external
processors can return a value, thus far placing these external processors
as AIML optional

--
sandro



>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
>
>
>_______________________________________________
>alicebot-archcomm mailing list
>alicebot-archcomm@list.alicebot.org
>http://list.alicebot.org/mailman/listinfo/alicebot-archcomm

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