> Hmmm, is that always going to be the case? I’d imagine that we (long term) > support the following types of sessions:
I think it will be. In fact, I would argue that the possible future proliferation of session mixing is another reason to have a SPDY client session, so that we can have a matching SPDY server session when/if that's useful. If we end up wanting to bypass HttpSM, *at that point* we should create a real SpdySM that manages the connections, and we would want to have a client session object for the same reason we use it with the HttpSM now. Having thought about this more I definitely think this is the way to go. It gives us a very nice model for our current SPDY implementation and a clear path forward when that's needful. It solves the problem of tracking the actual protocols used for a transaction - you can simply walk the client session chain and there you are. Adding plugin API to do that is trivial. It avoids having to track that data on the NetVCs, something that really breaks the abstraction and is complex. I'll try to do a better write up this weekend and pull out my ultimate design argument weapon - pictures!
