GOPHER 2.0 - GRUMBLINGS

Hey, I hear you. :-)

I  want  to  keep part 4/4 "The Client" as short as possible.  So
I'm posting this first as an interlude.

Let's get the main disclaimers out of the way:

1. Ignore the title "Gopher 2.0" - I'm just sticking with  it  to
keep continuity.

2.  I  completely  agree with those who have argued that *Gopher*
should remain exactly as it is if for no other  reason  than  for
old hardware and software to keep working.

3. After the next post, I'm going to switch to non-technical con-
tent for a while.  So if this arrived  and  made  you  roll  your
eyes,  just  skip  it and don't give up on the old Ratfactor just
yet. :-)



Simplicity
=================================================================

I've  seen the word "simple" used a lot lately when talking about
Gopher and I want to address that.

I guess there are different kinds of "simple":

Allowing any sort of text encoding is  simple...   Except  you're
just offloading the difficulty of dealing with detecting and dis-
playing different text encodings to the client.

Having directory listings is  simple...   Except  the  format  is
something only a computer could love.

A  lack  of  hyperlinking  in  content is simple...  Except we're
still gonna use them, so you're just making a human copy-paste  a
path.

The  inability to re-flow text is simple...  Except it means text
content is horrible to read on smaller displays.



True simplicity
=================================================================

I  really can't state it better than Solderpunk from "The soul of
Gopher" [0]

     "Arguably, a protocol [without a  hard  line  between
     menus  and  documents]  has a stronger claim to being
     minimalist and simplistic than one with it, all  else
     being  equal.   What could be simpler than everything
     being the same kind of thing?"

Same thing with text encoding.   7-bit  ASCII  is  already  valid
UTF-8.   You're  probably already serving it.  What could be sim-
pler than going ahead, requiring it, and being able to *depend on
that*?



I don't want something complex
=================================================================

I've been a professional Web developer for two  decades.   I  was
building Web applications in the early years of the browser wars.
I've watched the complexity of the Web grow into what it  is  to-
day.   My  day  job  is working on a boring and massive Web-based
business application which actually *needs* all of that complexi-
ty in order to function.

I'm  here reading and writing on Gopher because when I come home,
I want something simple!  I don't want advertisements and pop-ups
and  megabytes  of JavaScript and all that crap just to read some
text.

(I also like the community.)



I just like improving things
=================================================================

I want to be able to build clients and servers and experiment and
have those experiments be "first class citizens" on a platform.

I can do that with Gopher.  I love that.

I'm not attacking Gopher.

I see room for improvement.  I can't help it.  That's what I do.

If I see something that's not working perfectly, I want  to  make
it better.

Unlike  the  "real world," when you get something right on a com-
puter, it *stays right*!

That's why I program computers in the first place: I love  making
the computer do the work!



Sharing ideas
=================================================================

Look, I think we all know the chances of introducing a new proto-
col/markup/client  that  takes  off and becomes popular are about
one in a million.

This is all just "ideas in the shower" and I'm writing them  down
because I can't help it.

I'm sharing them because others might be interested.

That's it. :-)

Thanks for reading!

 [0] gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/the-soul-of-gopher.txt