MBOX-Line: From mrc at CAC.Washington.EDU  Fri Jun  1 13:55:38 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Subscriptions in IMAP
In-Reply-To: <3770.1180685763.825922@peirce.dave.cridland.net>
References: <alpine.OSX.0.99.0705301048240.11683@pangtzu.panda.com>
	<20070530113546.Q27473@orthanc.ca>
	<alpine.WNT.0.99.0705301146290.5388@Shimo-Tomobiki.Panda.COM>
	<BF01B191-D34E-47DE-A4FB-EAF1CADE4715@apple.com>
	<1180563766.32181.2028.camel@hurina>
	<alpine.WNT.0.99.0705301555120.2080@Shimo-Tomobiki.Panda.COM>
	<8046.1180599490.471444@peirce.dave.cridland.net>
	<alpine.OSX.0.99.0705311326310.13729@pangtzu.panda.com>
	<3770.1180685763.825922@peirce.dave.cridland.net>
Message-ID: <alpine.OSX.0.99.0706011310460.27093@pangtzu.panda.com>

On Fri, 1 Jun 2007, Dave Cridland wrote:
> Witness keywords and flags, for instance - that's certainly a shared 
> configuration situation, yet for the most part IMAP clients have a tendancy 
> to either ignore the flags they don't recognise, or present them fairly 
> neutrally. And that's even with the distinctly unclear usages, like $LabelX, 
> as used by the Mozilla Mail/News clients.

I think that is because keywords languished in obscurity for so long. 
Throughout the 1990s and early 2000s people used multiple mailboxes to 
categorize messages instead of using keywords.  Now that Gmail has come 
along, the pendulum is moving back.

I await the first client that, observing the current 30 keyword per 
mailbox limit in UW imapd, automatically creates $BlurdyBloopMail1 through 
$BlurdyBloopMail30 to claim the space for itself.

> Actually, I've noticed a distinct change over the years. This used to be the 
> case, but increasingly, applications are designed toward cooperation.

Such is still very much a work in progress, and by no means accomplished; 
but this is not the appropriate forum for my grumbles on that topic.

>> This, in my mind, is what doomed ACAP.
> Like so many things, don't knock it until you've tried it. :-)

Don't get me wrong.  ACAP was well-intentioned.  After all, UW was a 
primary instigator of ACAP, on the grounds that IMSP was unsatisfactory!

>>   It's easy to blame ACAP's overengineering (and it did have that!), but 
>> the more fundamental flaw was the notion that applications could share 
>> configuration without abusing it.
> Actually, there's very little of that flaw in evidence amongst the 
> (admittedly small) deployments I've seen.

You've just stated my point.  ACAP does not demonstrate large-scale 
sharing of configuration since it is little-used.

Even more damning is your account of how Mulberry abuses ACAP.  If a good 
guy like Cyrus could screw up that way (and I consider him to be pretty 
close to a "best case"), just think about what would happen when lesser 
developers are in the game.

> Both ANNOTATE and METADATA have this protected space 
> too, of course,

With little deployed use, and ending up becoming Experimental...

> whereas traditional IMAP flags are considerably more ad-hoc 
> in this respect, and there's only a one-size-fits-all subscription list - 
> which is perhaps why the latter suffers so much.

My personal belief is that subscription list abuse came about because of a 
certain individual's misunderstanding of warning about not using the * 
wildcard in LIST.  Said individual interpreted "LIST * is inefficient" as 
meaning "do the inefficient LIST * once, then put it in the subscription 
list so it doesn't have to be done again."  This represented a complete 
misunderstanding as to why the * wildcard is bad.

Subsequent clients copied this behavior as "this is what you have to do in 
IMAP."

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

