[gopher] gopher++ (gopher1) protocol

Kacper Gutowski mwgamera at gmail.com
Mon Jan 11 14:18:29 UTC 2010


On 2010-01-11 14:48:55, Kim Holviala wrote:
> Now that wasn't too hard? Definately easier than coding PDF support
> into the client. Now all the server has to do is to stitch those two
> images together (there might have been a convert option for that
> too).

Not as easy as coding PDF support into server, right?  No, really
that's not a point.  Conversion may be possible for some certain formats
but it's wrong to rely on it especially on the server side where end user
has no control on what's going on and has no idea whether the result
is similar to the original or not.

And it's wrong to concentrate all the load on the server.
Gopher may be enough unpopular these days that this won't hurt but
why should we rely on this?

Basically server should serve data that was put on it.  If I want it
to be more accessible I'd put a version in more accessible format,
preferably plain text (preferably English because of problem with
encoding).

> Except that, of course, you don't. Neither do I. We don't do it
> because we just don't care. A theoretical C=64 user will care,
> though, but that's his problem for not using the latest Firefox on a
> quad Xeon, right?

Don't you think that it would be MUCH easier to care instead of
bloating a server with this conversion stuff?

Latest Firefox - that's an interesting subject on its own.
Current web browsers became oversized and bloated with features that
are required by various standards and with a lot of other features
that nobody ever use.  And what's even worse current Firefox has only
partial support for gopher (unless fixed with additional software like
Overbite).  But you see, not so long ago there was a rule of thumb
saying that your web design is bad if it's not legible in text-based
browser.

-- 
Kacper Gutowski



More information about the Gopher-Project mailing list