[gopher] Re: Gopherness

[nunojsilva@xxxxxxxxxx (Nuno J. Silva)]

"Matthew Holevinski" <eylusion@xxxxxxxxx>
writes:
> On Mon, Aug 4, 2008 at 1:08 PM, Nuno J. Silva
> <nunojsilva@xxxxxxxxxx> wrote:
>
>> "Jay Nemrow" <jnemrow@xxxxxxx> writes:
>>
<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.
>
> 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

Mimetypes are already available in what you call Gopher 1.x.

> 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

If changes need to be made, I'd do it in the same way it was done with
gopher+, zero or little tweaking is needed to make old clients
compatible.

A transaction on 'which protocol version are you?' is not defined in
'gopher0', therefore such a thing would have to be part of a new,
different protocol.

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

If a text document is written using ASCII only, that's readable as
ASCII and also as utf8 and iso 8859 (those charsets include the ASCII
characters, which are assigned exactly to the same values).


> 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

We have a protocol, gopher, rfc1436, and an extension, gopher+[1]. Even
if there are clients and servers which do not support gopher+,it works
well because gopher+ was implemented nicely in top of gopher.

[1] gopher://VE131.jumpjet.info/00%5cBegin_Here%5cReferences%5cGopher%2b.txt

If somebody wants something to be done with gopher, there's nothing
better than discussing it, not only to know what would be the best way
to implement that in top of gopher without breaking anything, but also
to know if it is really needed to implement it, if it is possible to do
that with gopher/gopher+. And IMHO this mailing list is a place to
discuss this sort of stuff - at least at an initial stage. If the
feature really requires a new protocol to be designed, then the design
should be discussed elsewhere.

If some feature is not achievable using the existing gopher protocol
(and gopher+), or if using it (even if through gopher+) breaks things
(as in, prevents access to the core information provided by the
selector) for users of older gopher clients, a new protocol should be
considered only if the feature is really needed - it might be better to
drop it and stay with plain gopher+.

Sometimes, a feature can be added to gopher+, let's say someone wants
gopher users to be able to know the number of pages of a postscript
document, the only thing required at the server side is to add that
information to the gopher+ attributes (and of course the server needs to
be a gopher+ one). (Client-side handling could not allow the user to see
that data, but it's more a gopher+ client design choice - the client
might allow the user to hit a key and get a screen with the gopher+
attributes for the specified selector, or the client can forbid direct
access to that information, and use internally only the attributes it
knows how to handle.)

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

-=-=-
``You know you have been raytracing too long when ...
 ... You've been asked how you did that thing you did, by the autor of
 the raytracer you used to do it.''
 -- Alex McLeod