1922155 - IMAP hierarchy delimiter handling should be confined to the protocol code, and not bleed out into folder (and incomingserver)

Status: NEW

(MailNews Core :: Backend, task)

Description

[Ben Campbell]

IMAP servers can specify which character to use to delimit paths into the mailbox hierarchy on the server. (eg "invoices/July" or "invoices^July").

When mailbox paths are passed to and fro between the IMAP protocol code (nsImapService, nsImapProtocol et al) and non-protocol code (nsImapIncomingServer, nsImapMailFolder etc), it's never too clear what transformations and escapings need to be applied to a path.

It would be nice to define this better and clear up the inconsistencies.

Bug 124287 testifies to the amount of grief this causes.

So I think the server hierarchy delimiter should be confined to the protocol side, and all paths passed back and forth should be in an "canonical" server mailbox form (probably using '/' as delimiter), with robust escaping/unescaping rules.

Ideally this canonical form would be protocol-independent, so we can share more folder-side code between different protocols (eg a generic protocol interface for renaming a folder on a server, say, or for creating a new subfolder. Kicking off these kind of operations should be the same for all the protocols, and could easily extend to local folders).

Comment 1

[Ben Campbell]

To take the example of nsIImapServerSink.nsIpossibleImapMailbox(), which is a function implemented on nsImapIncomingServer:

Its signature is:

boolean possibleImapMailbox(in AUTF8String folderPath,
                              in char hierarchyDelimiter, in long boxFlags);

You'd think that folderPath would use hierarchyDelimiter as the path separator.
But the protocol code has already canonicalised folderPath to use '/' as separator before calling possibleImapMailbox().
So the hierarchyDelimiter just confuses everything. I suspect it's still passed because some calls to, say nsImapService, expect paths to be specified using the server-defined delimiter.