From: gopher-bounce@complete.org Date: Tue Aug 5 00:58:56 2008 Subject: [gopher] Re: Fate of the Protocol (was Re: Gopherness) Are you offering to host a new list? Not everyone has the resources to do so, you know. And of course you wouldn't want to use port 70 to serve notgopher, that would be silly. The best idea seems to be to modify the Gopher protocol in non-backwards-compatible ways (adding headers of some sort to ever resource grab seems to be the big change every other desire relies on) and then serve it on a different port, as well as old-style Gopher on port 70 - in a similar way to how pygopherd currently serves http on port 80 and gopher on port 70. The real reason to do this is only to try to hit a middle ground between http and gopher, really. HTTP is huge, unwieldy, and powerful, while gopher is small, simple, and arguably less powerful. Trying to hit a balance so we can handle some more complex things (like download progress indicators and passing files to the right program on the client side) while still keeping things simple enough that cheap, simple (or old) hardware is still all you need to get the basic features out of it. I suppose there's also the gopher+ route of adding extra fields (which actually might be a better option), but is there any way to do that when you send a magic string? It'd be really nice if a client didn't have to know the item type for something before it requested it, but if we keep serving on port 70, we obviously have to send that information in such a way that it doesn't confuse old clients. Thread start (DIR) [gopher] Fate of the Protocol (was Re: Gopherness) Thread start (DIR) [gopher] Fate of the Protocol (was Re: Gopherness) (DIR) Followup: [gopher] Re: Fate of the Protocol (was Re: Gopherness) (DIR) Followup: [gopher] Re: Fate of the Protocol (was Re: Gopherness) (DIR) Followup: [gopher] Re: Fate of the Protocol (was Re: Gopherness) (DIR) Followup: [gopher] Re: Fate of the Protocol (was Re: Gopherness)