I read through the patch documentation at the link provided and it appears that the dual-use implementation hides the details from the client. If that is the case then all existing clients that use UW-IMAP should work.
Am I missing something? > From: Mark Crispin <[EMAIL PROTECTED]> > Date: Wed, 01 May 2002 18:13:16 -0700 (PDT) > To: [EMAIL PROTECTED] > Subject: Re: Dual use patch page > > On Thu, 02 May 2002 03:03:23 +0200, Friedrich Lobenstock wrote: >> So please be so kind and elaborate a bit why dual-use mailboxes >> make life harder for imap complient clients. > > The IMAP protocol has a mechanism to determine whether a mailbox is dual-use > or not. > > Broken clients do not use this mechanism and instead assume that all mailboxes > are dual-use. They break in wierd ways when a mailbox is not dual use. Some > even require the user to set a configuration option to say "this server does > not have dual-use mailboxes" which half-works to undo the brokenness. > > Good clients understand when a mailbox is dual-use and when it is not. > However, when a mailbox is dual-use, it becomes more complicated for the user. > The user can no longer select a name and have it open a list of subordinate > names (directory) or open a message browser (mailbox). Instead, the user now > has to choose between commands to either open the name as a directory or open > it as mailbox. > > The result is extra complexity and confusion for the user. We see this > frequently in Pine when the user switches servers to a server. Suddenly, the > user is confronted with usage complexity that he never experienced before > > The design of the UW server is to maintain compatibility with UNIX conventions > and traditions. Above all, the traditional UNIX format support is focused on > compatibility with the past 30 years of UNIX mail history. mbx, although not > a legacy format, by design shares many of the same attributes including > compatible naming with traditional UNIX format. > > There are other servers which do not have the goal of compatibility with UNIX > conventions and traditions. If incompatibility is a closer match to your > needs, then you should consider those servers. >
