[alicebot-archcomm] My reply to Jon's thoughtful reply to: My thoughts on "Fetching Info from the Web"

Wed, 30 Jul 2003 03:00:10 -0400

Jon (earlier):
>Hmm, I thinking I see the light, maybe ;-) So you'd just want something kind
>of like a cgi script way of doing things? Send a request to the interpreter
>(prolly via a form), get it's output, and send that to the client? Which is
>close to what J-Alice already did, except it used a template, which couldn't
>be changed at runtime, but was somewhat customisable.

Gary:
Yes, Jon!  You got it.  I apologize for not being clear.  I want FORM 
submission.
And of course a little more :).  Cold Fusion, and other middleware/scripting
languages, are often busy supporting applications that thrive on passing
URL and FORM data back and forth. So, in an attempt to be even more
clear, here is a scenario of how things might work:

Let's say the application is an A.L.I.C.E. bot that specializes in helping
new home buyers with newbie information. The user asks her "What is
today's 30 year loan interest rate?"   Now, once the pattern is matched,
our gal has a couple of tasks at hand:

1) Since we don't know just how long it will take to get the information,
we need for A.L.I.C.E. to have an optional way to say a message while she is
busy finding the answer to the question.  She might say "Hang on a
second, I'll look that up for you ...".  In some environments and for some
requests, the reply can be so fast, this step can be skipped and so
should be optional.

2) Because sometimes the connection may fail or the server may be down,
we need to have the ability to set a timeout value that will trigger a failure
condition if the response time is not reasonable.  I can imagine that if a
response typically takes 1 second to get back, setting the timeout to 6 
seconds
might be a reasonable thing to do.  A default value could be 10 seconds,
and it might be a value stored in a bot defined variable.

3) Since a timeout failure could occur, we need to give A.L.I.C.E. a way
to supply a falure message like,  "I'm sorry, my sources for interest rates
are not available now.  You might try asking me again later."  A  more
generic message could be triggered if the programmer did not provide one.
"I'm sorry, that information is not available at this time."

For evaluation's sake, let's say that the task at hand is for A.L.I.C.E. to
make contact with the ficticious server called www.GetAnythingYouWant.com,
pass it three URL variables which in turns triggers two responses back from
the server.  The three URL variables are  URL.RequestID , URL.UserID, and
URL.Password.  The URL.RequestID is a string = 'Get_30_Year_Interest_Rate'
and URL.UserID='Alice_User' and Password='EekAMouse' .

It is time to pause a moment to reflect where this data might have
come from.  All of the URL data, and even the domain name, could have
be values found in BOT variables.  So, my friend, we must have a
way to tell our FORM within our TEMPLATE just how to get this data.
Also,  everything we say about the URL variable data (sent via GET) has to 
apply to sending
the alternate type of variables used by forms, or FORM variable data (sent 
via POST).

OK, so we continue.  The FORM action in the TEMPLATE manages to
deliver the data and www.GetAnythingYouWant.com processes the request
and returns the results in an HTML document supplying the requested data.
The FORM action has a way to store that data in a programmer defined BOT 
variable.
Since the process is completed before the timeout can occur, the FORM action
displays the "successful result" value which is a string that may only include
the HTML filled BOT variable or it may have other text surrounding it.  For 
example:
SuccessfulResult="Today's 30 year interest rate is <HTML data in bot 
value>".  Keeping the
results in a variable makes it reusable, perhaps saving some FORM requests 
from
having to take place in the near future.  Which brings up another issue....

... it would be nice for FORM action to have the ability to receive back 
from the
server data that automatically gets stuffed into specific BOT vars.
Perhaps included in the list of URL variables sent to the server are 
additional URL
variables with nothing more than a BOT Variable Name.  The server may 
ignore the
variable, but this gives FORM action permission to receive data back from 
the server
that will be stuffed in its respective BOT variable.

Continuing our example lets say we sent along with our URL list a null 
value variable
called URL.Effective_30_Year_Interest_Rate_Date. Then somehow magically (I 
need
to leave the hard part to you :)  the web server, in addition to coughing 
up the HTML page,
also spits out the value "July 30, 2003" for stuffing in the appropriate 
BOT Variable .  Now
I wonder if this BOT var can get created on the fly if it does not already 
exist, and if that is
a good thing?  And what happens if the server never provides data for it?

And another thought: We might need a way for further evaluation to take 
place based upon the
results are returned from the server.  Perhaps we could optionally deploy 
<SRAI> here.

  Anyway, this is what I have in mind so far, and I doubt I will want much 
more.

Can I have it tomorrow please :)  ?

-gr