Re: Protocols, extensions, compatibility

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
>
>
>
>