[gopher] Gopher++ scrapped & Internet Archive -style thingy

[Mike Hebel]

Kim Holviala wrote:
> On 20.4.2010 18:40, Mike Hebel wrote:
>
>>> * I cannot add anything to the client side of the protocol or old but
>>> still running servers will break - my gopher++ enchanced Mosaic for
>>> example refused to browse quite a number of existing sites
>>
>> Wait...what? You can't tell your client to only activate Gopher++ when
>> it sees your server? Isn't there _any_ sort of identification method in
>> the server protocol that gives you the server software name?
>
> There's the little difference between a 20-line patch and a 200-line 
> patch to an existing client. Identification requires a lot more code 
> and I just wanted to have a few simple additions.

Yeah but once it's done it's done.  Regardless I'm amazed and grateful 
for the coding you _do_ on this stuff.  It's just plain cool. :-)

> Well how about this - make the Gopher++ identification file based. If
>> the client detects gophernicus.txt then enable Gopher++ for that session
>> otherwise don't.
>
> That requires keeping state in the client which I don't want to 
> require. Right now a gopher client doesn't have to keep ANY state 
> between page loads.

But we're talking about _your_ client here.  If you have to keep a state 
just for _your_ type of server I can't see that as too bad a thing.  And 
from reading the stuff about spidering you already have a caching 
routine handy...

> ----
>
> It's easy to send extra data from the server to the client in 100% 
> backwards-compatible way (type 1 menus have a lot of unused space for 
> sideband data). My TITLE resource proposal was an example of this - it 
> doesn't break ANY existing client, no matter how old and simple.
>
> But, I need a way to do the opposite - I need a way for a client to 
> send extra data to the server in such way that old servers won't 
> break. I haven't found a solution to this yet - and I mean a solution 
> that doesn't require probing and keeping state in the client.

The only way I can see this coming about is the one thing you don't want 
to do - probe the server for identification and then keep the server 
state for that host+session.  I can't think of any other way it could be 
done.

A note on your comment about "life support".  I've been in the industry 
about about 20 years now (currently "in transition" *cough*) and it 
seems to me there is a need for a simple, lightweight,  easily 
configurable, easy to use, file serving method.   FTP is a nightmare, 
SFTP is sometimes blocked by ISPs/netnannys, and bittorrent is actively 
being hammered into the ground as fast as the media companies can do 
it.  (I don't think it'll go away but it certainly will be throttled to 
all hell.)

Now add to all this that we're getting closer to IPv6 where _everyone_ 
has a public IP.  That means potentially everyone is a server.  A 
modified form of Gopher could easily fill that role.

1) Store files in the "Gopher Hole" on your desktop that can not be 
shared by other means via whatever O/S security method is available.

2) That "hole" is shared only by Gopher+++ out to the world on your IPv6.

It wouldn't be a file transfer mechanism but rather a pure "read only" 
way to serve up files to friends and family using a simple server on 
your end and a simple client on theirs.  (Standalone/runnable not 
have-to-install.)

-- 
Mike


Manamana!