31 Dec
2010
31 Dec
'10
2:32 p.m.
A big part of the process isn't getting the TCP/IP
code correct, but
learning how to program in this environment. Buffer space is limited
and most events are asynchronous. The programming environment is pretty
barren - the lack of threading would probably be the most jarring
limitation for a programmer used to current systems. That means keeping
a lot of state per connection, constantly polling, and avoiding
operations that can block for a long time.
Well, that's what I mean. Gopher is about the world's easiest protocol.
The client sends you a selector on a single line, you reply with data and
the connection closes. No authentication, no state (except for the state
of the socket itself), no headers, no wacky encodings. You can doll it up
but even dolled-up gopher has all the dolling-up done on the data side
responding to custom selectors; the actual command-response model is still
just that simple.
This is part of the reason I don't like the increased reliance on HTTP
because HTTP is being turned into something that it isn't. For example,
WebSockets? Really?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- And if I claim to be a wise man/it surely means that I don't know. -- Kansas