Subject: [gopher] Re: ASK blocks in practice
From: Stefan Rieken <StefanRieken@SoftHome.net>
To: gopher@complete.org
In-Reply-To: <20010122121219.B17731@mothra>
References: <20010121231920.A14344@mothra>  
	<20010122111235.30433.qmail@softhome.net>  <20010122121219.B17731@mothra>
Content-type: text/plain
Date: 30 Jan 2001 19:30:25 +0100
Mime-Version: 1.0
Message-Id: <20010130183017.D44DC7CC2@hirogen.kabelfoon.nl>
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


OK, so you want a better ASK, _without_ having to change client
software?

You do realize you're asking for a real hattrick, do you? :-)

But having worked all day debugging my own ancient and buggy CGI script,
I'm in to some REALLY ugly hacks right now, so here goes! ;-)

(rhetoric) What are the current client's capabilities?
* It receives directory listings, lets the user select one of the files
  in that listing, and then it will ask the server for that file, after
  having examined the file type first.
* If the "file" is an index server, the client asks the user for one
  single query string.
* If there is a question mark after the extra Gopher+ tab, the client
  asks the server for the "+ASK" "file attribute", interprets it, and
  presents the user with a form as a result of this "+ASK" attribute
* After selecting anything, be it a normal file, an index file, or an
  ASK file, the client expects back a directory listing or a file of any
  data type

The problem lies in the fact that the ASK part of the protocol is so
over-simplified that the client and server can only handle a predefiend
amount of predefined variables.

At this point, it is important to note that the Gopher and Gopher+
protocols do provide a wealthy set of extension possibilities. It should
really also be considered to just introduce a new datatype, a new file
attribute, or extra data after the extra "\t" or after the "\r\n". While
these solutions would require server AND client to be adapted in order
to recognize this new extension, this _is_ a very clean way of dealing
with this problem, the cleanest way around. You should really consider
using these capabilities.

While you consider that, I'll go on with exploring the possibilities for
my ugly hack.

For this hack, we'll have to use the clients current capabilities only,
so that is need not be extended.

The /only/ capability a client has to ask the user for a variety of
data, is the current ASK implementation. So we _have_ to use it as our
basis. On top of that, the client should be able to send the server
*more information* about the data it sends in return to an ASK block, or
about the data it needs to ask in the first place. To give this extra
data in a compatible way, I see no other way then to hide it in the
selector string.

The "more information" that we need:
* variables passed by name instead of just by location in the ASK return
  block
* the possibility to pass a variable number of variables, and different
  variables on different occasions

Let's illustrate what we have with an example. This example script first
asks you for your username and password, and if that is OK it will let
you see other data (don't care what). If the password is not OK, it will
tell you so, give you the opportunity to try again, or to register.
Let's see how this will work:

* The user selects the script from a directory listing; the client
  program recognizes this as an ASK script and asks the server for the
  +ASK block. The selector will look _something_ like this:

    path/to/script?username&password
    [or "path/to/script?username=Ask&password=AskP", whichever is
    easier]

* The server recognises this selector as such: "this is an ASK script,
  and it needs the variables `username' and `password'". It will [in an
  as yet undefined way] tell the script to prepare the ASK block for
  these two variables. The server will send that ASK block back.
* The client program now receives this ASK block, and so it knows to ask
  the user for a username and password. The client will send the
  selector above to the server, followed by the answers to the ASK block
  (just as is standard).
* The server now invokes the ASK script, somehow passing the two
  variables "username" and "password". It knows which variable names to
  use because it interprets the query string.
* The script examines the values and does whatever it has to do with
  them. If the username and password are not correct, it may decide to
  spit out a directory listing similar to this one:

    iBad username or password\thost.org\t\t1
    1Try again\thost.org\tpath/to/script?username&password\t70\t?
    1Or make a new
    account\thost.org\tpath/to/script?newname&newpassword&retypepw\t70\t?

    [please ignore any protocol mistakes I made, this is tongue-in-cheek
    stuff]

* The client may then select any of these strings (except for the `i'
  string of course). The first one should make the script asking for a
  username and password again, the second one should make the script ask
  for different stuff (where "newname" could be a new user name, etc.).

Summary
=======
The above example shows a way (a "method and apparatus" -- let's get one
of them fancy software patent for this rubbish! ;-) for a Gopher+ server
to enable the client to pass a variable amount of named variables to a
server-side script without requiring any extra intelligence on the
client side. It is an ugly hack by nature, but it might be useful. If it
turns out to be so, work still needs to be done on defining the exact
syntaxis of the query, and on the protocol for the dialog between the
server and the script.

This method vaguely resembles the GET method in HTTP, where data is sent
as part of the selector. In more complex cases, this method leads to
very ugly URLs. The POST method hides the data from the user.

It might be considered to also provide a POST-like solution for sending
our [meta]data which new clients would recognize, while older clients
would handle the GET-like method, similar to the way Gopher clients may
ignore Gopher+ extentions. I haven't had time to give that a thought,
and as I have to go away now, it'd be for another occasion.

Greets,

Stefan

-- 
The difference between Murphy- and RFC 1123-SHOULDs:
RFC 1123-SHOULD: You SHOULD implement this part of the protocol...
Murphy-SHOULD  : ...and then it SHOULD work as expected.