[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Thank you for this very good response.

Barry Leiba writes:

 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.
Maybe you're right. But I know two cases where a perceived lack of readability/blah delayed implementation for literally years, and my part of the world isn't very big. 

(And yes, I'm as guilty as anyone else.)


 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.
I know the page and think not, but it's close-ish. This would be more helpful, e.g.: 

  [ extension name ]
     known supporting servers: [ list ]
     known unsupporting: [ list ]
     test accounts/downloads with: [ list ]


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).
or, pedantically, (3) they need the functionality and providing an IMAP interface is essentially cost-free.
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.
I think you're right, at least for all the relevant extensions I can think of now. 

Do me a favour. Repost that list at each WGLC.


...
(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.
A couple of hours ago someone sent me mail saying essentially «blah issues 350 SELECTs and 350 SEARCHes and it's unpleasantly slow». I think the sender might just possibly consider multimailbox search to fit group 3 ;)
INTHREAD searches are a bit like that too. With that you can add a checkbox in the search dialog: 

   [ ] return entires conversations
That's a pure added feature. It's also possible to use INTHREAD differently in clients (e.g. send 350 THREAD commands in addition to the 350 SELECTs above), of course.
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.
Yes. I though that was a little too... shall we say, the likelihood of highly unpleasant discussions seemed high and the advantage for me small. 

Arnt