[alicebot-archcomm] The saga continues (2): "Fetching Info from the Web"

[Gary Robertson]

Nice to hear back so soon from you, Ernest.  -gr

Ernest (earlier):
>*Flush* only works in an ASCII or a VoiceXML environment but not on a
>browser, especially if embedded in HTML tables i.e., where the browser
>has to wait for </table>.
>
>*Server push* needs a special formatted HTTP message and works only on
>Netscape/Mozilla but not on M$IE. [1][2]

Gary:
Can you think of an alternative way to handle this?  How do you present a 
"Gee, just a moment while I get that for you" message, and then go fetch 
the response, and then return with an answer ... presented all in one page?

Ernest (earlier):
>AIML 1.01. has now 34 tags.
>
>Don't you think, that defining a dozen or more new tags just to add a
>single functionality is a little bit overdone?

Gary:
Considering the amount of real value the tags add to the platform, I would say
the ratio is about right.  From what I can see so far, the SOAP approach adds
even more overhead for the developer, it is just pushed elsewhere out of the
immediate view and perhaps makes life easier for the interpreter developer, 
but
at the expense of the application developer.

Ernest (earlier):
>Moreover there are some basic XML faults in your example:
>
>><mlsid = "<get name='mlsidvar'>">
>Such a construction is not allowed: You can't have XML tags inside an
>attribute value. [3]

Gary:
Acknowledged.  So what would be the best construction to achieve the same goal?

Ernest (earlier):
>><"price">
>><"address">
>><"htmldoc">
>Quotes are not alllowed in XML tag names. [4]

Gary:
Acknowledged.  Can we just remove the quotes and have it work OK?

Ernest (earlier):
>Using SOAP has the advantage for any AIML interpreter, that it is easy
>to implement because of the availability of SOAP APIs in many
>programming languages. We only have to define, what has to be exchanged,
>name the services etc. and two or three AIML tags for the interface.

Gary:
I am less concerned about finding a SOAP for any AIML interpreter use;
I am much more concerned of the hassle the developer has to undergo to
deploy SOAP on his .cgi site, while in contrast simple FORM processing is 
immediate
and universal.

None of the applications I am involved with have issues with trust that is 
not easily
handled at the application level, but data security through the Internet is 
another matter.
https: can be deployed to manage the concerns for security that I would have.

I continue to hold the belief that there is a need for the more direct 
functionality as I
am proposing.  But, since you have the skills, maybe you would consider 
implementing
a trial version your ideas for SOAP soon, so we can experience first hand 
exactly what you mean.

I am not afraid to be converted, but I do have to "believe"!

-gr