Huh. The only thing other than the name that I really hate about "Web 2.0" is that it's on top of HTTP. Kludge after kludge trying to be stateful with a stateless protocol.

At least that's how I feel when programming web apps.

Kludge after kludge is how you produce good software!

I have worked on flight control systems that encompass 20+ years of iterative development, with no roadmap and no feature plan more than 18 months into the future. (So about 30~ iterations so far, 25+ of which were unplanned by the original architechts.)

In that time the hardware has been expanded, by passed, ripped out, upgraded and abused. Yet the software today is still fantastically reliable, feature rich and _because of this very method of development_ contains a vast quantity of captured lessons from past use.

Every round of development starts with 'this is what we have, this is what we want, how do we get there with minimum change?' because other methods just don't work as well in our experience.

Implementing stateless protocols over stateful protocols over stateless protocols is powerful and minimises the leakiness of your abstraction. Interface (stateful) over HTTP (stateless) over TCP/IP (stateful) over packets (stateless) is desirable.

> that's how I feel when programming web apps.

HTTP is extremely verbose with 0.4KB headers in each direction and JavaScript was originally a domain specific language to implement features within Netscape3.0. Neither are optimised for current usage.

Do you have any recommended reading for the whys of implementing protocols like that?

Layering stateful and stateless protocols minimises abstraction leakiness ( http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... ) while maximising future re-use.

Unfortunately, I cannot recommend any books on the subject. People who write successful protocols spend their time maintaining successful implementations. People who write books about protocols have typically implemented protocols which are used within small niches, if at all.

If you want to learn by example then the best suggestion I can give is to read RFC821 (email delivery) ( http://www.faqs.org/rfcs/rfc821.html ), RFC822 (email headers) ( http://www.faqs.org/rfcs/rfc822.html ), RFC1094 (NFSv1) ( http://www.faqs.org/rfcs/rfc1094.html ), RFC1813 (NFSv3) ( http://www.faqs.org/rfcs/rfc1813.html ), RFC3010 (NFSv4) ( http://www.faqs.org/rfcs/rfc3010.html ), RFC1436 (Gopher protocol) ( http://www.faqs.org/rfcs/rfc1436.html ), RFC1459 (IRC protocol) ( http://www.faqs.org/rfcs/rfc1459.html ), RFC1945 (HTTP/1.0) ( http://www.faqs.org/rfcs/rfc1945.html ), RFC2616 (HTTP/1.1) ( http://www.faqs.org/rfcs/rfc2616.html ) and supporting documents for a mix of text and binary protocol specifications, reasonings and evolutions.

If you're not accustomed to reading RFCs then they may seem quite terse. Persevere and it will get easier after the first five or so. At the very least, read RFC822 because it is the basis of web and email headers.

Thanks. I'm not exactly accustomed to reading RFCs (I am accustomed to reading terse specs), but those look like exactly what I'm looking for.