MBOX-Line: From dave at cridland.net  Fri Jun  1 01:16:03 2007
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Subscriptions in IMAP
In-Reply-To: <alpine.OSX.0.99.0705311326310.13729@pangtzu.panda.com>
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>
Message-ID: <3770.1180685763.825922@peirce.dave.cridland.net>

On Thu May 31 21:45:42 2007, Mark Crispin wrote:
> On Thu, 31 May 2007, Dave Cridland wrote:
>> I'm not blaming Mark, or the others involved in RFC3501 here - 
>> it's understandable that the semantics of a subscribed mailbox 
>> weren't fully described in the original design, because the intent 
>> was obvious - unfortunately, as time has moved on, it's less 
>> obvious, and requires a certain degree of archeology to detirmine 
>> what the intent was, and besides, we have multiple clients 
>> gradually pulling the intent in different and contradictory 
>> directions.
> 
> There is a deeper problem.  The idea of having a generic mechanism 
> to support a common concept fails, more often than it succeeds, 
> whenever it depends upon a cooperative use of that mechanism.  All 
> it needs is one bad actor to render the mechanism useless, and to 
> cause all the other actors to flee back into a protected space that 
> it controls.
> 
> 
In a lot of cases, even that's not too bad, as long as the protected 
space is available. I think there's a general attitude toward trying 
to use facilities and specifications interoperably, at least if at 
all possible.

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.


> The bad actor problem afflicts many areas.  Consider what happens 
> when you install a media player to play a specific file.  It 
> doesn't just install that program.  It also sets that program as 
> the default media player for all your other media files; puts an 
> extra icon on the desktop, the start menu, the quick launch 
> taskbar; and adds a launcher to the notification area.
> 
> 
Actually, I've noticed a distinct change over the years. This used to 
be the case, but increasingly, applications are designed toward 
cooperation. It's not helped by the general design of the desktop 
systems which push toward a single application for a single task, and 
I don't think it's entirely fair to blame the applications in this 
instance. (Desktops such as GNOME seem to promote the concept of a 
default application for a media type, plus lots of alternatives, yet 
as far as I can tell, there's still a single application granted 
responsibility for each URI scheme).

> This, in my mind, is what doomed ACAP.

Like so many things, don't knock it until you've tried it. :-)

>   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. The only instance I can 
recall is where Mulberry changes addressbook entries by deleting and 
recreating them, thus losing all attributes it doesn't understand 
(including some standard ones, as well as any vendor-private ones). I 
happen to think that's bad ACAP whichever way you cut it - it'd be 
like removing all user-defined keywords on a message if you set the 
\Seen flag - and it breaks inheritance chains as well.

In my opinion, ACAP is particularly well-designed in this respect, as 
it provides the "protected space" that the applications can control 
to handle their own requirements. (Of course, this also becomes 
responsible for part of the over-engineering). Both ANNOTATE and 
METADATA have this protected space too, of course, 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.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

