Re: Protocols, extensions, compatibility

Watching this video, Patrick McManus makes a great point about increasing
connections increases the likelihood that SYNs and SYN-ACKs will get
dropped. That's a very convincing argument for me AGAINST my suggestion to
simply increase the per host limit.

Thanks for sending the link,

Peter

On Fri, Mar 30, 2012 at 8:03 PM, Mike Belshe <mike@belshe.com> wrote:

>
>
> On Sat, Mar 31, 2012 at 1:10 AM, Adrien W. de Croy <adrien@qbik.com>wrote:
>
>>  Hi all.
>>
>> There have been some questions raised about whether the best way forward
>> is a new protocol, or patches to existing protocols etc.
>>
>> I'm sure many of you are familiar with IMAP, and on the imap-ext mailing
>> list recently there has also been discussion about exactly this.
>>
>> IMAP like HTTP was conceived a long time ago.  At that time, people
>> hadn't thought about all the things we wanted mail or web to do.
>>
>> So as time went by, the desires for features left an ever-widening gap
>> between what customers wanted developers to create to solve the issues they
>> faced, and what protocols would support.
>>
>> The classic response to this has been the definition of optional
>> extensions to the core protocol, or frankly hacks.
>>
>> This has happened in both HTTP and IMAP.
>>
>> The situation as it stands with IMAP, is that any IMAP client implementor
>> frankly has a number of nightmares on his/her hands.
>>
>> Because the extensions were by and large optional, and not independent of
>> each other (frequently RFCs for IMAP extensions alter other extension specs
>> for the case where both exist), a client has to deal with
>> an ever-increasing interdependency issue.  Clients need to be able to do
>> the same task in a multitude of different ways to cope with different
>> server option support.
>>
>> This results in ever-increasing complexity, increased risk of
>> implementation errors due to interdependencies, increased time to develop
>> features, and generally reduced performance.  Development gridlock.
>>
>> The same thankfully cannot be said for HTTP at the moment, although there
>> are a few areas where dealing with optional support makes life difficult.
>>
>> So, where am I going with this?
>>
>> Eventually a requirement may come along which simply doesn't fit with the
>> current protocol.  That's when it becomes interesting to consider starting
>> afresh.
>>
>> We may consider we aren't at this point with HTTP.  Personally, I think
>> things like long-polling are an indication that HTTP isn't doing what we
>> want, and currently doesn't support the semantics we want.
>>
>
> Patrick McManus did a nice presentation and discusses how 'HTTP has hit a
> wall'.
>
> http://www.ducksong.com/codebits11/
>
> He makes some similar points, but discussing mostly at the connection mgmt
> & protocol level.
>
> Video is here:  https://codebits.eu/intra/s/session/220
>
> Mike
>
>
>
>
>>
>> Adrien
>>
>>
>>
>>
>
>