Complete.Org: Mailing Lists: Archives: gopher: July 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: Jason Nemrow <jnemrow@xxxxxxx>
Date: Mon, 21 Jul 2008 13:41:34 -0600
Reply-to: gopher@xxxxxxxxxxxx

Although all your points are true, I am hoping to describe in Gopherness a =
way to view information through the gopher0 protocol.  It is limited in sev=
eral ways, much like Morse code is. I am trying to work out how to keep gop=
her0  useful, since there are a variety of computers, often older ones, tha=
t already have a gopher0 client and will likely never have www or "new goph=
er" clients.=20

I know Gopher0 is limited and feels very constraining to modern possibiliti=
es, just like Morse code does.  Gopher0 is still useful given is greater un=
iversality with older computers and novice programmers, much like Morse cod=
e (of which there is no Japanese version that I know of).  I know there are=
 more modern and expansive ways of communicating than both gopher0 and Mors=
e code, but both of these work now and will continue to work as long as the=
ir limitations are accounted for.

I am glad no one has proposed adding thousands of new codes in Morse code t=
o handle kanji or some other language set.  This would make it unlearnable =
and far fewer people could use it (or a lot of traffic would be undeciphera=
ble for certain people).  The same idea can be applied to gopher0, where th=
e current thinking skews to adding new ability through a variety of means. =
 It would either break old clients (which everyone is thankfully trying to =
prevent) or people would begin using the new extensions and whole swaths of=
 new content would simply not be accessible from older client/computers (re=
member, unrecognized types get ignored and can't be seen or accessed).=20

I guess I am just highlighting some limitations and saying that we should r=
espect those, rather than spending energy trying to work around them or fig=
ht them.  If you add a bunch of new characters to Morse code, it is now som=
e other code.  If you add a bunch of new things to Gopher, it is no longer =
Gopher and is some other protocol.

That is basically my point.

Jay

-----Original Message-----
From: "Kyevan" <kyevan@xxxxxxxxxxx>
To: gopher@xxxxxxxxxxxx
Sent: 7/20/08 4:15 PM
Subject: [gopher] Re: Gopherness

Interesting, but there are three things that I have reservations or=20
questions about.

> - Putting "up" or "previous menu" items in menus which points into your=20
> personal "data island".

Often times, pointing back up a tree makes sense, even if that's not the=20
tree the user followed to get here. I think the issue is probably more=20
with the title than the idea of putting a link to a menu 'above' this one.

> - Adding an Endless Array of New Item Types for Every New Thing that=20
> Comes Along

The issue here is letting the client system (the entire computer system,=20
I mean, not just the code that talks to gopher) distinguish between file=20
types.

 > - Rendering Everything Else to a Handful of Established Types.

The problem here is that you're assuming all, for example, images are=20
equal. JPEG works pretty well for photographs or 3d renders of lifelike=20
scenes, but often makes drawings, charts, graphs, and the like unusable.=20
This is the easiest to see, but even text has this issue - ASCII is=20
incredibly simple and to be preferred for most English-language=20
documents ("dumb" quotes over typographical ones, for example) On the=20
other hand, what if you want to upload a text in the original language=20
when that language wasn't English? Even most of the closely related=20
languages have accents or the like, and then you go out to things like=20
Japanese... you can see how this is a problem.

- Kyevan






[Prev in Thread] Current Thread [Next in Thread]
  • [gopher] Re: Gopherness, Jason Nemrow <=