Message-ID: <20010122111235.30433.qmail@softhome.net>
References: <20010121231920.A14344@mothra>
In-Reply-To: <20010121231920.A14344@mothra>
From: StefanRieken@softhome.net
To: gopher@complete.org
Subject: [gopher] Re: ASK blocks in practice
Date: Mon, 22 Jan 2001 11:12:35 GMT
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


I'm just doing this reply "for fun", I'm no ASK guru ;-)

Anyway, here goes.

David Allen writes:

> Do you guys think that ASK stuff is even worth the effort to extend?
> What are the other options available?  Are any of you using ASK blocks
> for anything?

Well, ASK is a little bit the CGI of Gopher, right?

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.

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):

@data = split (/\t/, $returnthingy);
if ($data[0] = "processing_state_one")
        {process_data_from_state_one ();}
elsif ($data[0] = "processing_state_two")
        {process_dta_from_state_two ();}
....etc.

So, that sucks.

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?)

(And well, anyway, only being able to upload a single file at once sucks
too... But how to do that with the URL style?)

Concerning the *implementation* of the ASK part of the Gopher protocol, I
think you're free to implement it any way you like. From the above, I guess
you already figured that *my* ideal implementation would be if, just like
with CGI, the script *itself* would produce the questions, *and* process
their answers, like this (again, purely hypothetical):

if (!$returnthingy)
       {spit_out_the_questions ();}
else
       {process_the_answers ($returnthingy);}

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.

Greets,

Stefan