On May 17, 2014, at 7:51 AM, Alan M. Carroll <a...@network-geographics.com> wrote:
>> 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! I still don't understand this focus on client session chaining. AFAICT there is no client session chaining other than an implementation detail in the current SPDY implementation. I don't see how client session is a general concept at all. J
