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 sitesWait...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. Ifthe 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! _______________________________________________ Gopher-Project mailing list Gopher-Project@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/gopher-project