Chris McRae writes:
> Perhaps a more pertinent example is available in constructing an HTML WAIS
> interface. After receiving search results including interesting documents
> and some additional WAIS sources, the user will want to refine the search
> by selecting the interesting items and re-searching:
> <FORM ACTION="TEXTSEARCH wais://cnidr.org:210/$search_spec?blah">
I understand what you want to do, I just disagree with putting this
into HTML and the client.
FYI: TEXTSEARCH isn't a valid method it's just an attribute of an
object (e.g., Accept: TEXTSEARCH). Same goes for SPACEJUMP. The
query is still done with a GET like always.
All of this can be done in the protocol within the confines of POST
*and* be much more flexible. For example, redoing your example:
document:
Select A stored query:
<FORM ACTION="http://server1/select"> <SELECT NAME=query> ...
request:
POST /select HTTP/1.0
...
query=BLAH-directory-of-servers.src?foobarbatbaz
response:
HTTP/1.0 302 Found
Location: wais://waisserver/BLAH-directory-of-servers.src?foobarbatbaz
...
Ta-da. And now I can redirect all the queries on the fly (gee, think.com
is down, lets try xyz.edu) *without* having change ANY of the documents.
You need to use a different method than POST? No problem, just reply
like this:
HTTP/1.0 303 Method
Method: ADMIN http://blah.com/BLAH-directory-of-servers.src
...
See, no need to change the protocol, or add crap to HTML or add a limitless
amount of code to EVERY client. Hacking stuff like this into client is
an intractable solution to the problem, there are too many variables and
things are changing too fast. The server side solution that HTTP implements
let's you scale the solution with the problem.
--sanders