Re: [MORG] Why IMAP extensions are (not) used

[Barry Leiba <barryleiba at computer.org>]

> 1. RFCs written with the wrong audience in mind.
>
> Many of the RFCs don't make much effort to serve client authors or answer
> their questions, such as «how should I use this?», «how should I fall back
> when it isn't supported?». Some RFCs have few examples, some have many, but
> «many» is not the same as «useful for a particular audience».

I suspect the number of examples is not a factor at all in decisions
whether to implement an extension or not.

In fact, I suspect that how the RFC is written is, in general, a minor point.

> 2. RFCs can be hard to find.
>
> We don't have a list mapping from problem/benefit to the relevant
> extension(s), and googling doesn't solve that problem well.

This amounts to "publicity", and, surely, the most implemented ones
may correlate with the most publicized ones.  Alexey once has a web
page with a list of which implementations support which extensions.
That also addresses your point 4.

> 3. What if/ifnot.
>
> Clients generally need to implement stuff both for servers that support a
> given extensions, and for servers that don't. We haven't given much thought
> to minimising the duplicated code paths that result, or do it cleanly.

This is really the nut of it, I think.
Servers will implement an extension if (1) it's so easy that they
might as well, or (2) they perceive a demand for it (from clients or
from customers -- the latter is sometimes just a box they have to
tick... yes, we support that).

Clients will implement an extension if (1) it really saves them a lot
of programming work, (2) it really saves a lot of performance, (3) it
provides a feature that they can't get without it, or (4) they
perceive a demand for it (see above).

Your point 3 shows that (1) is basically not possible the way
extensions are implemented in IMAP.  For POP, the TOP and UIDP
extensions, for example, are essentially required.  Any server that
doesn't support them will fail, and clients regularly just assume
they're available and refuse to work with servers that don't have
them.  So it's easy.

Lacking that, though, client developers have to do *extra* programming
to support extensions, because things have to work both ways, as you
say.

(2) mostly coves things like searching, sorting, and threading on the
server, and a few things that save a lot of bandwidth or round trips
for situations with slow connections or ones with high latency.

(3) mostly covers IDLE.  Pretty much anything else can be done another way.


What it comes down to is that (1), above, is the critical point.  As
long as the extensions are "extensions", sparsely (and perhaps
buggily) supported, things will be difficult.

There was a small effort started to trim things from IMAP that might
be better done in other ways (like folders) and to fold in the
"important" extensions to a new base.  The effort was called "IMAP5",
and it seems to have died down.

Barry