[alicebot-archcomm] Thank you Ernest Lergon. My thoughts on "Fetching Info from the Web"

[Jonathan Roewen]

> Like any other religion, one's very own platform of computing knowledge is
> sacrosanct.  Once we neophyte programmers have a set of tools that more or
> less works for us most of the time... we think we are a god. That is,
until
> we are forced to use something else.  Then we face a grief stricken
> barrier.  Just like facing the misery of learning another word processor
or
> spread sheet, for many of us, learning another language or database is
> worse than suffering through a daily flogging.

Hehe, yes some programmers are like that .. and then there are those that
love to learn new languages (like me), and get to know their strengths and
weaknesses .. no language is universally perfect, no matter what anyone
thinks ... well, at least not yet ;-)

> I am a self-taught HTML guy. In the early days of Internet, I used to
teach
> an introductory class to 30 new students each week with passion, zest and
> zeal.  Why?  HTML was simple, it made sense, and it worked.  No big deal,
> of course.  I mention this only to show you why I quickly gravitated to
> Cold Fusion as my preferred middleware language, since it sported those
> friendly and easiy-to-understand and easy-to-remember  tags, which for me
> became a natural extension of HTML.  And from there I was introduced into
> SQL via the simple, yet powerful interface provided by MS Access.

Ah yes .. simple things put together to do complex things is an idiom of the
UNIX world .. that's why pipes were so important ;-) Any good intro to UNIX
shell programming would tell you that =)

> OK.  So this is my current and rather small programming world.  And since
> Macromedia acquired and extended Cold Fusion, I am somewhat assured that
it
> will continue to grow and be well-supported.  MS Access and its bigger,
> more powerful SQL brothers and sisters are not going away anytime soon;
nor
> is HTML.  And so far - I can do just about anything I and my clients have
> ever thought about doing with these tools, until I met "her".

=) Yeah, she is quite amazing...

>  I believe
> that the key to AIML reaching its full potential now lies in ensuring that
> it can "fit" with all of the other parts easily enough.
>
> So what does that mean?  To me it means that AIML must expand its reach to
> insure that I can use "my"  HTML and "my" middleware language and "my" SQL
> and especially all of "my" current routines.  I must have access to these
> things in a very straight forward manner with minimum additional "thought
> overhead".  It means I must be able to transfer "bot-variable" data to my
> routines, and receive data from my server-side routines and transfer it
> into bot variables at will.  And "sometimes"  I just want to take the
> output that I have previously formatted for the web and use it "just as
> is".  BTW, this need to keep the data output format 'the same' has more to
> do with 'rapid development' requirements than anything else.

This is what the use of xml namespaces is supposed to allow. I am sure you
are aware of those, as if I'm correct, ColdFusion tags, by default, are
added to html/cf documents using a namespace to separate them from html and
other tags.

> If as a developer, I can make these things happen using standard, or near
> standard HTML-like FORM-POST-SUBMIT and FORM-GET-SUBMT command structures
> and interfaces that I am already using, then I am estactic.

It should be doable either already, or pretty soon. All you really need is
an interpreter that can handle namespaces correctly (so it leaves namespaced
tags uninterpreted, and in the output), and that can be plugged into other
systems/applications (this is the new goal of J-Alice and it's completely
new line of development).

One way could be to link an interpreter into Apache, for example, and
letting Apache know that to process documents containing an <aiml:category>
(given the namespace for "aiml" is correct) that it should be processed by
the AIML interpreter .. allowing server-side processing of the AIML content.
I don't know Apache that well, so I'm not sure if it's able of doing things
like that .. perhaps you know more about that sort of thing.

>  If I  can
> somehow get returned ATTRIBUTE-VALUE variable data and transfer it into
BOT
> variables using some simple ASSIGN (with default value) statement; and,
> allow standard HTML return data to display "as is", then life would indeed
> be grand!  What I submit to you is that this handful of functionality is
> limited enough, yet powerful and universal enough in scope to more than
> satisfy the 80/20 rule while keeping the interface independent of any
> particular cgi-scripting language.  It is my guess that this is also
> universally deployable over a large pool of "likely-to-be-used"
> interpreters, or lesser interpreters with addon 3rd party Internet I/O
modules.

Transferring data would probably be possible too, again, probably through
the use of embedding AIML's category tags in the document.

Another interesting approach would be to send a request to an AIML document,
and have the output fed to Apache .. I'm not sure how putting server-side
scripting in an AIML document would work in that manner .. maybe it wouldn't
.. but at least client-side scripting would still work.

> Once a developer buys into the potential of AIML., the first obstacle he
> faces is understanding the basic nature of a category.  The next obstacle
> he faces is how is he going to interface it into his own programming
> world.  The first is what it is. The second is what I have addressed here,
> and what we have the power to make much better.

And the second is what I'm trying to achieve too .. perhaps we might be on
the same wavelength ;-)

Jon