From: gopher-bounce@complete.org Date: Tue Aug 5 00:48:52 2008 Subject: [gopher] Re: Gopherness How about Versions? If http, went from 1.x 2.x 3.x 4.x etc. so on. Why not gopher. I think i understand the problem with the item types and mime subjects everyone is talking about, it appears as though if one server employs a type of mime for file type differences a client used to item types might get confused and vica versa, then everyone has discussed a myriad of ways to implement both or either features including others. Could we not worry about breaking old gopher protocol and we could do somet= hing like releasing versions of a new gopher server, hopefully this wouldn't create bloatware but what if say there was a new Gopher implementation that is fully compata= ble with the old standards, and we could call that version 1.x, and then clients that are compatible with all old standards would be 1.x compliant. Now, when som= eone would want to say release mimetypes instead of the itemtypes, all those little additions could be say Gopher 2.x, but here's the trick with the clients, I guess I supppose when a client negotiates a connection with a gopher 2.x server and it's only 1.x compatible(only a label), the server could send just a teeny tiny datapacket saying hey are you old skool or new skool, at which point if the client responds i'm 1.x yo' the gopher server could either say, okay your too old for me come back when you update, or some type of uber server script that rewrites it's data in realtime, like, if the entire gopher filesystem is in mimetypes and such, it will know better say when sending mime/mpeg or whatnot to be retrieve as itemtype 9 or whatever it is, so the older client would know how to interpret the data. Seems to me all a lot of these features, could be backwards compatable, and I'd hate to see the size of the server software grow considerably in size, but wouldn't a new server software that just says Hey, I'm Gopher Server Side Software version 1x, I include all that is gopher+ and oldschool, then get everbody to work on some new gopher daemon that doesn't break, what gopher is philosophically and now technically. Therefor, say, if your client understands what's going on when it's talking to say Gopher 2.x, it won't have any trouble understanding subclasses of plain text, like ascii, or UTF-8, no biggie, but if the server realizes the client is an older client it'd just convert the UTF-8 to ascii on the fly, and then we could all agree on something right? Or is all of that just not possible? Understandingly, i have absolutely no idea what I'm talking about, everyone is getting all worked up over some minor details. I don't see why a new (or existing) gopher server daemon, that's tried and true to the way it was back in the early nineties can't, encompass a lot of these changes everyone is equating to what should happen or how these things should be treated, when this improved server could handle all the new functionality everyone wants to see put into it, but if parsay an old client comes a long, the new server just won't be able to "transcode" back down for them. That way everybody is satisfied. Matt On Mon, Aug 4, 2008 at 1:08 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote= : > "Jay Nemrow" <jnemrow@quix.us> writes: > >> On Mon, Aug 4, 2008 at 10:19 AM, Kyevan <kyevan@sinedev.org> wrote: >>> What about older clients, though? Modern clients will probably handle >>> UTF-8 at least well enough to not explode, but older clients might not. >>> Generally, it seems safest to stick to the subset that is ASCII when >>> reasonable, only using UTF-8 or such when it's actually needed. ... is = a >>> perfectly readable replacement for U+2026, even if it's not >>> "typographically correct." On the other hand, if you're trying to post = a >>> text in, say, a mix of Arabic, and Klingon, go right ahead and use >>> UTF-8. > > There are also these iso* charsets which just use 8 bit to encode the > text, not allowing a greater collection of characters, and using those > you wouldn't be able to mix charsets. > > For iso*, AFAIK, some sort of character detection, or configuration > would be required on the client side (it is possible to do that getting > the document language using gopher+ - and URLs pointing to the specific > view (even if it is just one) would be required to autodetect when > browsing a non-ASCII URL). utf8 will have to be supported, for the small > (but not zero) scenarios in which two non-ASCII alphabets are mixed in > the same text, and auto-detect would fail (unless a special language > code is used for mixed-language documents, or if the client handles more > than one non-english language (if it is allowed to specify more than one > in the gopher+ attributes) as utf8). > > On the other hand, even if the choice was utf8 (so the documents would > be ASCII or utf8), I'd keep iso* support, just in case (therefore my > question is 'should we use the same sort of character encoding when > publishing non-english documents? if yes, which one?' and not 'what > should a client support?'). > > What's the actual scenario? Is there any client which crashes due to > utf8? Which clients are not able to render it correctly? And what about > iso* charsets support? > > <snip/> >> If we do a version of Gopher which is basically new (adding UTF-8 or >> MIME or whatever), I think we should ask for and get a new port >> assignment for it. If you wanted Goph08, send the request through a >> Goph08 port number. Gopher request continue to go through port 70. >> Just have your server listen on two ports instead of one, using the >> old idea that if you are using a different protocol (essentially), you >> should use a different port. (Crazy idea, I know.) I guess this gets >> back to an old point, which is that a modern version of Gopher is >> essentially a new protocol and should be treated as such. If you guys >> want to change Gopher to "improve" it, it ceases to be Gopher. >> "Updated" nostalgia is not nostalgia at all. > > Adding a new way to do the mime part would be a reason to make another > version of the gopher protocol, or a protocol under a different name, > but about utf8, it's not about gopher, it's about the way text is > rendered by the client, not requiring any change in the protocol. > > -- > Nuno J. Silva (aka njsg) > LEIC student at Instituto Superior T=E9cnico > Lisbon, Portugal > Homepage: http://njsg.no.sapo.pt/ > Gopherspace: gopher://sdf-eu.org/11/users/njsg > Registered Linux User #402207 - http://counter.li.org > > -=3D-=3D- > ``Now we'll have to kill you.'' > -- Linus Torvalds > > > >