Scott Carey wrote:
I also have not wrapped my head around routing/proxy use cases. From a somewhat ignorant perspective on them -- I'd rather have a solid point-to-point protocol that just works, is simple, and can meet the vast majority of use cases with high performance than one that happens to be capable of sophisticated routing but has a lot of other limitations or is a lot harder to implement and debug.
FWIW, they're theoretical at this point. I was only stating that prefixing every request and response with handshakes makes stuff like proxies trivial, since the protocol becomes stateless. Once we start having sessions things get trickier. For example, many HTTP client libraries cache connections, so, if you're building on top of one of those, it's hard to know when a new connection is opened.
One approach is to declare that the current framing and handshake rules only apply to HTTP, currently our only standard transport. Then we can define a new transport that's point-to-point, stateful, etc. which may handle framing and handshakes differently. Thus we can retain back-compatibility. Make sense?
Doug
