Complete.Org: Mailing Lists: Archives: gopher: August 2008:
[gopher] Re: Gopherness
Home

[gopher] Re: Gopherness

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Gopherness
From: nunojsilva@xxxxxxxxxx (Nuno J. Silva)
Date: Mon, 04 Aug 2008 19:08:17 +0100
Reply-to: gopher@xxxxxxxxxxxx

"Jay Nemrow" <jnemrow@xxxxxxx> writes:

> On Mon, Aug 4, 2008 at 10:19 AM, Kyevan <kyevan@xxxxxxxxxxx> 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écnico
Lisbon, Portugal
Homepage: http://njsg.no.sapo.pt/
Gopherspace: gopher://sdf-eu.org/11/users/njsg
Registered Linux User #402207 - http://counter.li.org

-=-=-
``Now we'll have to kill you.''
 -- Linus Torvalds




[Prev in Thread] Current Thread [Next in Thread]