1. Using HTTP does not save having to properly format requests or parse answers. What makes exchanging messages by means of an HTTP library easier than exchanging messages by means of the socket library that that HTTP library is built on?
2. Hm, maybe. Or maybe using HTTP would increase the need for such mechanisms. ...How much would be cacheable, anyway? About the only thing would be fetching past posts, and I'd expect most of that to come from web frontends anyway (which would have their own caching).
3. HTTPS is just HTTP over SSL. SSL is available without having to use HTTP.
4. Hm. Maybe dns SRV records could be used to get around needing a port assignment, and what firewalls would actually matter? I'd think it would be like smtp/pop/imap, people just use webmail clients and their firewalls don't care.
5. :) I just don't see that requiring http for something that would in practice be almost entirely for server-to-server communication would actually provide any benefits.
...hm. I included a spec on how to make posts thinking that it could also be used by client programs, but the connect-back design for forwarding messages wouldn't work for that. :(
1. HTTP includes verbs to handle everything you mentioned. Posting is a POST, listing is a GET, getting a single message is a GET, subscribing is a POST, deleting is a DELETE, etc.
2. Many networks use proxies and caches such as squid, varnish, etc. My servers are locked down with iptables, and I would have to open up ports in order for them to speak a new protocol
3. What's your point? Your protocol is just a layer over TCP. Why not just use TCP? And TCP is just a layer over IP. Why not just use IP? Following your logic takes us back to early DOS days where each program drives each piece of hardware directly.
4. Your argument against using HTTP is that ... people are just going to use HTTP anyway?
5. With libraries such as Rack and WSGI setting things up to speak HTTP is too easy. Not to mention node.js, mochiweb, etc.
TCP provides reliable streams, which IP doesn't. HTTP takes those reliable streams and provides... what, exactly? I guess it turns the streams into request/response message pairs (with lots of extra headers), but that's not nearly as useful - especially since parsing messages out of a stream really isn't harder than understanding the contents of the messages themselves.
2. Hm, maybe. Or maybe using HTTP would increase the need for such mechanisms. ...How much would be cacheable, anyway? About the only thing would be fetching past posts, and I'd expect most of that to come from web frontends anyway (which would have their own caching).
3. HTTPS is just HTTP over SSL. SSL is available without having to use HTTP.
4. Hm. Maybe dns SRV records could be used to get around needing a port assignment, and what firewalls would actually matter? I'd think it would be like smtp/pop/imap, people just use webmail clients and their firewalls don't care.
5. :) I just don't see that requiring http for something that would in practice be almost entirely for server-to-server communication would actually provide any benefits.
...hm. I included a spec on how to make posts thinking that it could also be used by client programs, but the connect-back design for forwarding messages wouldn't work for that. :(