At least that's how I feel when programming web apps.
At least that's how I feel when programming web apps.
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.
> 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.
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.