Soweli Lukin


            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!


Soweli LukinIssuesAlex Schroeder