34 lines
1.4 KiB
Plaintext
34 lines
1.4 KiB
Plaintext
MBOX-Line: From mrc+imap at panda.com Wed May 19 13:18:07 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc+imap@panda.com>
|
|
Date: Fri Jun 8 12:34:43 2018
|
|
Subject: [Imap-protocol] Namespace questions
|
|
In-Reply-To: <201005192009.NAA28384@Panda.COM>
|
|
References: <201005191535.o4JFZP5Q013449@mxout14.cac.washington.edu>
|
|
<alpine.OSX.2.00.1005190859110.29651@hsinghsing.panda.com>
|
|
<alpine.BSO.2.00.1005191049260.23411@vanye.sendmail.com>
|
|
<201005192009.NAA28384@Panda.COM>
|
|
Message-ID: <alpine.OSX.2.00.1005191313420.29651@hsinghsing.panda.com>
|
|
|
|
On Wed, 19 May 2010, Pete Maclean wrote:
|
|
> The one end-user product I have that incorporates the server is used
|
|
> primarily with clients on mobile devices. In this case I am inclined
|
|
> to not cross namespaces primarily just to limit the amount of data
|
|
> sent in LIST responses.
|
|
|
|
It may be more work than you want to undertake right now, but it very much
|
|
sounds to me that a chimera type solution, such as what I did in my new
|
|
server, would work best for your end users.
|
|
|
|
It's more what the end users will want anyway. Namespaces were designed
|
|
to solve a specific problem, not to force its use. It's unfortunate that
|
|
it was overloaded to incorporate "here's how to find other users" and
|
|
"here's how to find public mailboxes".
|
|
|
|
-- 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.
|
|
|