PROTOCOL PONDERING @ SOLDERPUNK

I wanted to respond to Solderpunk's 3-part epic on the subject of
gopher-likes. [0-3]

This won't make much sense unless you've read those, which I rec-
ommend  you  do  anyway if you have any interest in the conversa-
tion.



Part I
=================================================================

I think it's a great idea to compare and contrast Gopher vs HTTP.
In particular, the way HTTP request headers have been  abused  to
work against us by advertisers (and worse) on the Web.

I  completely agree that there's no compelling reason to have re-
quest headers of any kind.  They solve problems  that  we  simply
don't have.



Part II
=================================================================

I'm not convinced we even need response headers.

I'll admit that Status codes and having the ability to signal  to
a non-human client that, "I have failed" is a really, really com-
pelling argument.

On the other hand, I wonder if we really need a header for  that?
What  if  we just say that if the entire contents of the response
is the string "NOT FOUND", then you have a "not found" error?

Generally, in-band "special values" like this are considered  re-
ally  poor engineering - after all, somebody could create a docu-
ment containing that text and the client would interpret it as an
error.

But I say, "so what?"  If you want to be a cheeky monkey and have
an error-producing document, what's the harm?  Heck,  that  might
even  be  considered  a feature...hmm... I'll have to think about
that.

I 100% completely agree that Gopher's lack of content-type  iden-
tification is the wrong kind of "simple".

But given the option between having to do MIME detection and pro-
ducing a header on the server side and *then* parse the header on
the  client side and try to handle potentially exotic text encod-
ings... versus just requiring UTF-8, I vote for the latter.

For the gain in simplicity, I'm okay with the loss of  flexibili-
ty.


Part III
-----------------------------------------------------------------

I'm firmly on the side of not differentiating between  menus  and
content  -  I believe this is friendlier for content creators and
easier for the developer.

It's easier to explain to newbies.

Searches...

Searching is really interesting and it's true that you need  some
way of indicating a search path to the client.

I think you could specify a search link in several fairly obvious
ways.  But here's a _fun_ one: what if any path that  ends  in  a
'?' (question mark) is a search path?

Example:

  gopher://example.com/foo/search?

Tangent on searches:

Take  that  one step further, and maybe you can try searching any
directory by appending a '?' to it:

  gopher://example.com/foo/?

If the server doesn't support this, it could return an error  (in
the form I suggested above) such as "NO SEARCH" or some such.

Anyway, continuing on...

One  thing  that we both love about Gopher and I agree 100% with:
having one link per line.

I don't care for the tab-separated, Gopher-menu-inspired  syntax.
But that's a minor quibble.

To  me, line-based syntax in general is wonderful because it's so
easy to read, write, and parse.

I'm tempted go one step further than suggest that links not  even
have  display  text.  Just a raw link.  Let the client shorten it
as needed, but otherwise let this bare link be visible to the us-
er.

I'm not sure.  I could go either way.



The end
=================================================================

Thanks for the thought-provoking stuff, Solderpunk!

  [0] gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/protocol-pondering-intensifies.txt
  [1] gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/protocol-pondering-intensifies-ii.txt
  [2] gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/protocol-pondering-intensifies-iii.txt