Re: [gopher] gopher++ (gopher1) protocol
On 11.1.2010 12:33, Kacper Gutowski wrote:
So you've basically reinvented HTTP with slightly different syntax
and with all burden of rendering the content on the server side.
I don't think those two are the same things. Yeah, I took a lot from
HTTP/1.1, but that's not a bad protocol at all.
Although this may seem to solve some problems, you request that both
client and server become quite a complicated programs neglecting one
of the most important features of Gopher, i.e. simplicity.
Yes, servers would be *a lot more* complicated. But clients would be
simpler as they could count on the server to do what's being asked.
Consider this: you're doing a client to Commodore 64 and can only fit in
one image decoder routine. Which one would you choose? With gopher++
you'd choose the one that's easiest on the client resources and then ask
the server to serve out all images in using that format. With gopher0
you'll choose one format and all the other image formats are unaccessible.
Let's continue with the Commodore 64 example. Can you fit iconv() into
the little old C=64? No, you probably can't. So what will you do with
text that has high-bit characters? Do you count on it being Latin-1 like
the original RFC says? Do you trust it to be UTF-8? Do you try to
magically sniff the content charset? With gopher++ you don't have to,
just ask the server to send out everything in US-ASCII.
What if you want to read an HTML document through gopher on your C=64?
With gopher0 your client has to know HTML (and we know what kind of a
mess that is). How about PDF? Can you fit an PDF reader + everything
else into the C=64? Probably not. With gopher++ you'll just tell the
server to send text/plain and be done with it. Or if your C=64 gopher++
client knows GIFs you can just ask the server to serve the PDFs as GIFs.
The whole idea of server transcoding data for client is ridiculous for me.
Seems pretty good to me.... If we take 1 server and 100 clients, I know
where I would prefer my file format support to be - in the same place
where the actual files are.
- Kim
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: