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
James,
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.
In order to do other things (such as
On May 19, 2014, at 10:46 AM, Alan M. Carroll a...@network-geographics.com
wrote:
James,
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
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
I've been thinking about some of the SPDY issues that have come up and have a
couple of ideas.
First, the SPDY SM is really a client session. It handles input from a client
socket and drives the transactions through the system, without interacting
(directly) with any of the origin servers or
On May 16, 2014, at 2:29 PM, Alan M. Carroll a...@network-geographics.com
wrote:
I've been thinking about some of the SPDY issues that have come up and have a
couple of ideas.
First, the SPDY SM is really a client session. It handles input from a client
socket and drives the
