"Richard Bang" <[EMAIL PROTECTED]> writes:
>I have implemented the protocol. What I'm proposing is an option on a
>users mailbox settings that says "When deleting mail move it to folder
>XXXXX".
...
>Customers don't give a RA about what's in the protocol, they don't want
>to do "delete, expunge" they want their deleted items stored for a given
>duration and if we cant give it to them then we should not complain when
>closed systems (Exchange) wins on usability.

You surely don't mean all the subscribers of the IMAP mailing list when
you say "we", so I'm not sure what complaining this is warning against.
When a user demands a feature, architects (and marketing...) must listen
very closely to separate out what would solve their problem(s) and what
is just part of the analogy the user is using to describe their vision
of the Right Thing.


>I know this because we implemented the delete/expunge in our WebMail
>system. The single biggest complain we get is "why doesn't it delete
>when I press delete", when we explain about delete/expunge, we get
>"that's stupid why did you do that". An answer of "because that's how
>the guys that wrote IMAP think it should work" will not cut it and WILL
>result in more sales of Exchange.

The IMAP protocol does not require any particular style of display by
clients, so a complaint about how deleted messages are displayed can
only be 'passed back' to the protocol when there is no practical way to
do otherwise.  Short of that, it's a client issue.  So, do users
*really* require that the "list of messages that I have deleted" be
per-user (ala many POP3 MUAs) instead of per-folder?

If not, then treating the list of messages in a mailbox that have the
\deleted flag set as distinct from the not-so-marked messages and
displaying them separately would seem to answer the request.  With that
style you can even apply different expiration policies to different
folders.  The client would only send an EXPUNGE or CLOSE command when it
wanted to 'empty the trash'; partial emptying/expiring would be
performed using UID EXPUNGE.


(Having used a form of per-folder 'trash' for years, I have a hard time
imagining a situation where they would have a poorer interface/feel than
a common trash.  Thus my wondering whether that aspect is truly part of
the users' requirements.)
 


(If a user wants to use multiple clients, one or more of which doesn't
use this method of handling deleted messages, then they've generated
their own problem.  Note that extending the protocol to, say, add a
"file to trash" command would *not* solve their problem, because the
involved clients wouldn't know to use it.  Altering the meaning of
existing commands, on the other hand, breaks *all* clients because no
existing client could know about the new behavior; users would have no
way of knowing what to expect from a server.  Clients that already
provide some idiom for undoing deletes would have their work duplicated
or interfered with.)


Philip Guenther
[EMAIL PROTECTED]

Reply via email to