4 ms·

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 statele

by kaens 18y ago

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.

xirium 18y ago
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.
- kaens 18y ago
  Do you have any recommended reading for the whys of implementing protocols like that?
  - xirium 18y ago
    Layering stateful and stateless protocols minimises abstraction leakiness ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html 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 http://www.faqs.org/rfcs/rfc821.html ), RFC822 (email headers) ( http://www.faqs.org/rfcs/rfc822.html http://www.faqs.org/rfcs/rfc822.html ), RFC1094 (NFSv1) ( http://www.faqs.org/rfcs/rfc1094.html http://www.faqs.org/rfcs/rfc1094.html ), RFC1813 (NFSv3) ( http://www.faqs.org/rfcs/rfc1813.html http://www.faqs.org/rfcs/rfc1813.html ), RFC3010 (NFSv4) ( http://www.faqs.org/rfcs/rfc3010.html http://www.faqs.org/rfcs/rfc3010.html ), RFC1436 (Gopher protocol) ( http://www.faqs.org/rfcs/rfc1436.html http://www.faqs.org/rfcs/rfc1436.html ), RFC1459 (IRC protocol) ( http://www.faqs.org/rfcs/rfc1459.html http://www.faqs.org/rfcs/rfc1459.html ), RFC1945 (HTTP/1.0) ( http://www.faqs.org/rfcs/rfc1945.html http://www.faqs.org/rfcs/rfc1945.html ), RFC2616 (HTTP/1.1) ( http://www.faqs.org/rfcs/rfc2616.html 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.
    - kaens 18y ago
      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.
notauser 18y ago
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.

by kaens 18y ago

xirium 18y ago

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.

kaens 18y ago
Do you have any recommended reading for the whys of implementing protocols like that?
- xirium 18y ago
  Layering stateful and stateless protocols minimises abstraction leakiness ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html 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 http://www.faqs.org/rfcs/rfc821.html ), RFC822 (email headers) ( http://www.faqs.org/rfcs/rfc822.html http://www.faqs.org/rfcs/rfc822.html ), RFC1094 (NFSv1) ( http://www.faqs.org/rfcs/rfc1094.html http://www.faqs.org/rfcs/rfc1094.html ), RFC1813 (NFSv3) ( http://www.faqs.org/rfcs/rfc1813.html http://www.faqs.org/rfcs/rfc1813.html ), RFC3010 (NFSv4) ( http://www.faqs.org/rfcs/rfc3010.html http://www.faqs.org/rfcs/rfc3010.html ), RFC1436 (Gopher protocol) ( http://www.faqs.org/rfcs/rfc1436.html http://www.faqs.org/rfcs/rfc1436.html ), RFC1459 (IRC protocol) ( http://www.faqs.org/rfcs/rfc1459.html http://www.faqs.org/rfcs/rfc1459.html ), RFC1945 (HTTP/1.0) ( http://www.faqs.org/rfcs/rfc1945.html http://www.faqs.org/rfcs/rfc1945.html ), RFC2616 (HTTP/1.1) ( http://www.faqs.org/rfcs/rfc2616.html 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.
  - kaens 18y ago
    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.

notauser 18y ago

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.