Date: Mon, 22 Jan 2001 12:12:19 -0500
From: David Allen <s2mdalle@titan.vcu.edu>
To: gopher@complete.org
Subject: [gopher] Re: ASK blocks in practice
Message-ID: <20010122121219.B17731@mothra>
References: <20010121231920.A14344@mothra>
 <20010122111235.30433.qmail@softhome.net>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <20010122111235.30433.qmail@softhome.net>;
 from StefanRieken@softhome.net on Mon, Jan 22, 2001 at 11:12:35AM +0000
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Mon, Jan 22, 2001 at 11:12:35AM +0000, StefanRieken@softhome.net wrote:

> I think its abilities within the protocol are a little bit clumsy. I mean
> to say that the way the questions are given, and the way the answers are
> sent back -- well, let's just say I'm glad America didn't vote using
> Gopher. It is not clear at first sight what data belongs to what variable,
> and you have to know which variables are asked in order to be able to
> decipher the data. This is stupid, because almost any CGI script I've
> written in my life, asks for a /variable/ number of variables, and does the
> processing depending on which variables are set and which are not.

Yeah, that's kind of why I'm asking if people think it's worth
extending.  That it needs to be added to, or that something else needs
to happen in order to do some types of things with gopher goes without
question in my book.

> In order to do such a thing with the Gopher protocol, you'd have to send
> data a la INPUT TYPE="hidden" (is this possible?) describing in which
> "state" the script sent his questions, and then examine the data with the
> use of conditions, like this (hypothetical example):

I don't think this is possible...well, I haven't seen any
documentation anywhere that makes me think you can do this.

> Alternatives within the protocol may be archieved by applying something a
> la HTTP queries to Gopher, so like sending a selector
> "/my/selector?data=foo&moredata=bar" or so. Then the server should
> recognize this special URL as an invocation of /my/selector with these two
> variables set. But maybe a lot of clients that display a webbrowser-like
> URL entry already use this question mark stuff for Veronica queries.
> (Anyone?)

That question mark stuff with veronica is done differently through
extra fields in the request string AFAIK.  As for adding
?param1=foo&param2=bar, the server would have to be hacked to know
that anything after the ? isn't part of the file it's looking for.
Again the question: is it worth doing this, or should another facility
be used?

> Concerning the *implementation* of the ASK part of the Gopher protocol, I
> think you're free to implement it any way you like. 

As long as it's done neatly and on the server side in a way that
doesn't require the client to know what's going on, it should be OK.
I.e. if you generate a locator with those parameters in it, the client
can follow it just like any other selector.  Where I think I would get
into trouble with extensions is when the client has to do something
that it's not already capable of doing in order to participate in the
extension. 

> Concerning the question if ASK blocks are used by anyone... Well, I'm a new
> kid in town, and I haven't yet put anything of Gopher+ into my "Gnopher"
> client program (IIRC, ASK is Gopher+, right?? Well, anyway, I didn't do the
> ASK stuff as of yet ;-). And I never ran a server. So I'm not really
> authoritive here. But I would personally reccommend having *some* way of
> juggling around with data.

Yep, ASK is gopher+.  It's actually quite easy to deal with.  There
are only about 8 differen types of questions, sending the data to the
server is very straightforward (like everything else in the
gopher/gopher+ protocol).  The only "hard" part is the UI, and that's
not that bad.

-- 
David Allen
http://opop.nols.com/