James,
Monday, May 19, 2014, 7:45:29 PM, you wrote:
I will bow out of the naming issue just do whatever the consensus is.
> The default value of 1000 is *huge*. 10 would be better IMHO.
1000 was the existing hardwired value.
> We should not be adding more default entries to "records.config"; t
In response to this default value, most spdy servers I've seen use 256 for
this value. Take a look at net internals in chrome.
Brian
On Monday, May 19, 2014, Leif Hedstrom wrote:
> Agree with James, let's be consistent.
>
> -- Leif
>
> > On May 19, 2014, at 8:45 PM, James Peach wrote:
> >
> >>
Agree with James, let's be consistent.
-- Leif
> On May 19, 2014, at 8:45 PM, James Peach wrote:
>
>> On May 19, 2014, at 5:26 PM, a...@apache.org wrote:
>>
>> Repository: trafficserver
>> Updated Branches:
>> refs/heads/master c25fb7541 -> ce8304309
>>
>>
>> TS-2821 Add to default records.
On May 19, 2014, at 5:26 PM, a...@apache.org wrote:
> Repository: trafficserver
> Updated Branches:
> refs/heads/master c25fb7541 -> ce8304309
>
>
> TS-2821 Add to default records.config and tweak the name to be more
> consistent.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/traffic
(also CK supports 32-bit architectures)
On May 19, 2014, at 10:46 AM, Alan M. Carroll
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 client session is a gener
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 log
On May 17, 2014, at 7:51 AM, Alan M. Carroll
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 re