[alicebot-archcomm] Javascript HTML client instead of Template/Filter?

[Christopher Fahey [askrom]]

PART 1:
I sometimes wonder if it might be better to write a sophisticated
Javascript client for Alice, one that works similarly to the way the
AlicebotFlash client works - that is, all display work is done on the
client end, not by the server. I don't know Javascript well, but I've
always thought that the Alice HTML template seemed like a "non-minimal"
way of feeding data to a client. (Note that in light of the separation
between the *implementation* and the *specification* I don't think that
this is a problem.)

Okay, Imagine that your HTML page queries the Alice server via some
Javascript sending the <alice_in> data to the server, then the server
sends back the <alice_out> back to the Javascript, and then the
Javascript in the HTML page replaces the onscreen text fields in real
time, in HTML, without ever reloading the page. Again, I don't know
Javascript well but it seems like it could work. It would also seem more
consistent with the "minimal" concept of an ideal AIML implementation
being simply a "text-in/text-out" machine.

I've also tried to imagine how someone might use .asp or .jsp to
communicate with a generic "text-in/text-out" Alice, also replacing the
whole HTML templating structure in ProgramD. My thoughts on this are
quite foggy, but it seems like a valid approach and one that a lot of
people would like to use.

PART 2:
In any case, I remember a while ago there was some initiative to update
ProgramD's template/filter structure - to enable users to build their
own templates and filters at will. Here's the example JonB came up with
a while ago, and I always thought it was quite a good idea (and it
doesn't have anything to do with AIML's architecture)

http://localhost:2001/CHAT?template=mytemplate&filter=myfilter
  where   template = a file with the <alice_in> and <alice_out> blocks
in it
  and where   filter = a file with a list of all non-AIML tags to allow
to be included in the output text

I thought this model was quite elegant: You simply create two files, one
called mytemplate.data and myfilter.data, then you request them
separately in the URL. We can't assume that someone using an HTML-based
client wants to display all HTML tags, so it's important to be able to
request them separately. For example, I could have a filter allowing a
stripped-down HTML set that I want to use for several client platform
templates (such as HTML, WML, HDML, and even flash), but I could have a
no-tags-at-all filter for a plaintext client (such as AOLIM).

I've been looking forward to updating my AlicebotFlash client, but until
the templating is finalized I don't want to do it. Is there anything
going on in this department? Jon, how do you feel about this?

-Cf

[christopher eli fahey]
art: http://www.graphpaper.com
science: http://www.askrom.com