MBOX-Line: From dave at cridland.net  Wed Jun 21 06:34:09 2006
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] Re: [lemonade] Notifications for multiple devices
	per user
In-Reply-To: <3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local>
References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com>
	<666.1150807794.041102@peirce.dave.cridland.net>
	<p06300018c0bdecb8b35e@[192.168.1.13]>
	<B25B894D-F749-46C1-8DCC-655B6FAB3823@orthanc.ca>
	<1736.1150887949.021000@JOHN>
	<3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local>
Message-ID: <666.1150896850.579833@peirce.dave.cridland.net>

On Wed Jun 21 14:14:30 2006, Cyrus Daboo wrote:
> --On June 21, 2006 12:05:48 PM +0100 Dave Cridland 
> <dave@cridland.net> wrote:
> 
>> Well, I basically agree, so whilst I've not done the pictures, 
>> I've done
>> my best to find and document the reasons why trash mailboxes are a 
>> bad
>> idea on IMAP.
> 
> I'm sorry but this is just wrong - if the Trash metaphor is what 
> users are comfortable with then that's what the client should use. 
> The protocol should not dictate how information is presented to the 
> user and should be flexible enough (within limits) to provide ways 
> for clients to do that.
> 
> 
But the protocol simply doesn't provide that, and without some quite 
extraordinary server support, it won't.

I'm sure it's possible, in principle, for a server to present a Trash 
mailbox that is automatically populated with all messages marked with 
the \Deleted flag in any mailbox the current user has access to, but 
for the vast majority of implementations, I think that's impractical.


> Lets face it, the main reason clients do Trash with IMAP is that 
> that's what POP clients typically did plus users are already 
> familiar and comfortable with that UI metaphor because that is what 
> most file system browsers also use. I doubt very much it was done 
> just because that's what the developers wanted.

Indeed, users are familiar with a trash container with a relatively 
wide scope, and many client authors have provided such a container at 
either client-wide or server-wide scope.

The only mechanism I can see for providing that in client-side IMAP 
would involve continuously searching all available mailboxes for 
messages marked as \Deleted, and presenting the results as a locally 
generated virtual mailbox, or else using a real mailbox as an 
artificial trash mailbox, which has both interoperability and 
(lesser) efficiency problems.

The closest I can provide is a per-mailbox trash container, which is, 
I agree, a considerably reduced scope by comparison to what's 
typically implemented, and therefore expected, by the user. On the 
plus side, such a mechanism is fully interoperable with any server or 
client conforming to RFC3501 (Or, I think, even much older 
specifications).

You state in another message that what we should do in write a "best 
common practises for implementing Trash properly with IMAP", and 
that's one aim of what I've written - it may well be that there's a 
much better method for providing a metaphor closer to the expectation 
of the typical user, but I don't see it.

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

