Re: [imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Wed, Feb 15, 2012 at 03:57:30PM +0100, Arnt Gulbrandsen wrote:
> On 02/15/2012 03:43 PM, Bron Gondwana wrote:
> > So basically what I'd like to see us doing with email is LESS.  Less custom.
> > Less "it's so special".  Treat it like a generic bunch of data, and manipulate
> > it with generic data manipulation methods.
> 
> It sounds a bit like a reinvention of RFC 2244, which was too generic
> for people like me. Dave liked it, I think he still likes it, but he's
> really smart. Personally, I understood that 2244 could be used to do
> wondrous stuff in general, but when I read the document I wasn't able to
> connect it to any concrete wondrous applications for my work.

Oh yeah, ACAP.  It's on the list of things to look at.

> Optimising for really smart people risks leaving mortals unable to see
> any reason to write code for it.

Obviously you need to avoid getting so over-generic that you wind up
doing an anything protocol.  The anything protocol is always tempting.

The thing is - I don't mean leaving everything super flexible and
undefined.  I'm meaning more "don't define a separate custom protocol
with custom behaviour for everything".

For example (and I quote directly from ##imap on freenode over the past
couple of hours)

<IroquoisTwist> hello, is there a simple reason why my imap connected
                clients can't distinguish unread messages? (all messages
                marked as read)
<brong_>        IroquoisTwist, probably is a simple reason, but it
                depends on a lot of factors...
<IroquoisTwist> brong_: thanks, i found out my spam guard was "reading"
                the messages - turned it off and used local span
                filtering - all is well
<brong_>        sounds like a classy piece of software.  Forgot to put
                a .peek in did they?
<brong_>        what am I saying.  imap5 people - LOOK AT THIS
<IroquoisTwist> brong_: not too sure - end of my spam knowledge - it's
                called Spamassassin (preinstalled via cPanel)


Now, you could blame the authors of the spam scanner which wrapped
Spamassassin and called it via IMAP.  They're morons, no doubt.

But .PEEK.  Seriously?  Hands up everyone who has screwed that up
themselves or seen someone else screw it up over their entire time
of working with email?  I'll own up to having done it more than
once.

.PEEK is one of the warts that is out.  No side effects.  No magic.

Along with \Recent, which is also magic - it's a read only value where
EVERYTHING ELSE in the same space is writable (ACLs permitting), it's
defined in a way that makes multi-session a pain.  It's a wart.

And UNSEEN, but I already said that.  Why is 'STATUS UNSEEN' special,
and "* UNSEEN x" - complete with the contradictory "use your common
sense" definition...

Bron.