[gopher] Re: ASK blocks in practice

[Stefan Rieken <StefanRieken@xxxxxxxxxxxx>]

Op 30 Jan 2001 18:05:57 -0500, David Allen schreef:

> After the "\r\n"?  How would that then be distinguisable from data
> belonging on the next line?

In the selector that you send back to the server, _not_ the selector you
receive _from_ the server. IIRC some parts of the protocol use this to
send some extra data, but otherwise never mind.

> But this then jumps into the tarpit of encoding of various characters,
> particularly tabs, and disallowing & and ? in the name of legitimate
> selectors.  Unless encoded.

That was my first idea, but it's really limited; you have to extend the
client for this.

If you check back with my new example, you'll see that data is now NOT
send in the selector, but instead in an ASK block. This makes that the
client need not to be extended; it doesn't have to know anything about
the new selector syntaxis extension.

Please do not confuse my new idea's query string with my old idea's.
(The old idea was to use plain HTTP GET CGI query strings, but in the
new idea it only sends the _names_ of the data in the query string, not
the values.)

> This is a problem.  See above with the question of whether or not a
> script can legitimately output directories.

Well, I guess that with the current ASK implementation, a script should
normally _always_ output a single data type, and in 99,999% of the cases
this data type should be a directory. (It may be hypothetically possible
to have it output nothing but images instead - e.g. a different image
depending on the user's input), but I don't think anyone would ever use
that wicked capability in practice, anyway.)

Then I also guess that we have no choice but to have our "newstyle"
script also only to output directories. Is this a disaster? I guess it
isn't. As shown above, in 99% of the cases, this _is_ what is expected
from a script, anyway.

> I think it would be useful.  The question in my mind is whether or not
> the effort is the same or exceeds simply extending gopher.  And is
> extending gopher really even an option?  Sure it's fun to have your
> own private hacked server, but it does no good it 90% of the planet is
> using LameClient version 3.0 which can't talk to your extensions.

No, no no! _No_ client changes required! (Otherwise, I would have
thought of a much cleaner method!)

> > 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.
> 
> See, if you're going to add GET, then why not add POST?  And if you're
> going to do that, why not do it in a clean way by extending rather
> than hacking in the above fashion?  But then again, if we're going to
> implement GET and POST, then how long before somebody asks for
> cookies?  Do we want to reimplement HTTP in gopher?  :)  (I.e. is
> there a limit past which it isn't really appropriate to extend gopher,
> because you're playing in HTTP's sandbox, and why reinvent the wheel?)

We're only "adding GET" to the _server_. The client need not know a
thing about what's going on, really.

It _might_ be considered to have a method for _new clients only_ to
recognize this extention and handle the data transfer in a smoother way,
so that you'd get selector strings without all the `?foo=bar' rubbish
(so resembling POST where there is also no [meta]data in the URL).

But that's not required.


> > 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.
> 
> Well, the way ASK data is passed to programs right now is really like
> POST since it's all coming in on standard in rather than through some
> decoded URL.

Correct, but with this idea of mine, you would have to add some metadata
to the selector, describing the names of the variables, and possibly
some state info [not worked out]. That's why I compared this with GET -
because it adds ugly stuff to the selector, just like GET does.

> So I know I might be jumping out of the immediate frame of discussion,
> but is extending gopher to do these types of things worth it, or is
> that really what the web is for?

Oh, was _that_ your question? ;-) Right.

*Sigh.* I think you might be right, but I don't like the idea.

The modern use of HTTP really depends on its CGI capabilities. If Gopher
can't support stuff like that, is it strange that it's not an option for
many people anymore?

And we wouldn't even be there yet with just CGI. How about cookies,
authentication? Evil as cookies might be, they are used for personal
settings etc. all over. Implementing _such_ stuff in a
client-independent manner isn't doable at all. So I guess you're right
that all this might be not worth it.

But that also shows that Gopher wouldn't really live up for the future.
It's niche (webbrowsing without the hubbub) might not survive the
comparision to HTTP's niche (dynamical and personal approaches of people
and data).

BTW, could you tell me how the Gopher+ protocol is unclear and
misunderstood, as you said?

Conclusion: I don't know. If you feel like it, hack it in and see what
evolution thinks of it. For the more advanced stuff like authentication,
I do see limitations that couldn't be solved without introducing
Gopher++, but I don't think Gopher would survive yet another (backwards
compatible) protocol revision. But if we keep Gopher for what it is,
what does it make it _really_ different from e.g. LDAP? (OK, I _guess_
(I don't know much of it) LDAP isn't meant to be a "browser" protocol,
but with Nautilus supporting LDAP, for me it doesn't make any real
difference.) If Gopher really loses its niche by sharing all of its
advantages with a few more supported protocols like HTTP and LDAP, then
what is it still worth using it at all - not even talking about
extending and maintaining it?

Greets,

Stefan