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
>
>
>
>