Well, at least in Java I found it easier, if you could just setup a threed pool
with 2 fix threads instead of a variable thread pool, because then you have to
manage the number of concurrent connections/threads manually depending on the
"requests" attribute.
So, the number two makes more sense in theory, since it's enough to make BOSH
work. I can't think in theory how requests="3" would improve anything.
And it's easier in practice to implement (in my opinion).
So, effectively I see no point in allowing the requests attribute to take
arbitrary values > 2.
Similarily, the hold attribute.
1.10 says:
"If the client is not able to use HTTP Pipelining then this SHOULD be set to
"1"."
Since HTTP Pipelining has been removed now from 1.11, the value is always 1,
right?
And the requests attribute should always be one more than the hold attribute,
so it is always 2.
If both attributes have (now) fix values, why have them around anyway?
Christian
Am 11.12.2013 um 12:46 schrieb Winfried Tilanus:
> On 11-12-13 08:21, Christian Schudt wrote:
>
> Hi,
>
>> Why can there be more than two concurrent connections ("requests")
>> anyway? Or, what's the benefit, if you use, say 5. You said "you only
>> ever need two connections". This is something I wondered, too, while
>> implementing it.
>
> The only argument I have heard in favour of more than 2 connections is
> that it might be easier to implement in some cases. And in theory it
> opens the road to more concurrency. In practice more than 2 connections
> tend to break things in the situations where you really want to deploy BOSH.
>
> Winfried
