4 ms·
Implementing stateless protocols over stateful protocols over stateless protocols is powerful and minimises the leakiness of your abstraction. Interface (statef
by 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 agoDo you have any recommended reading for the whys of implementing protocols like that?
- xirium 18y agoLayering 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 agoThanks. 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.