99 lines
4.7 KiB
Plaintext
99 lines
4.7 KiB
Plaintext
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
|
|
|