Re: [Classpathx-javamail] Rework of mbox provider

[Chris Burdess]

Countach wrote:
> I think encouraging or defaulting the use of platform specific 
> separators is just as bad as merely allowing them. If the important 
> methods like getFullname() return platform specific, then you are 
> encouraging the embedding of these platform specific things into 
> config files and preferences files and so forth.
>
> It seems to me that whatever absolute file path names you initially 
> pass into JavaMail, have nothing whatsoever to do with the MBOX 
> separator character. As far as MBOX is concerned they should be 
> treated as opaque blobs or strings. You shouldn't have a need to 
> disassemble them. I know there could be a need if you call 
> Store.getFolder() with an absolute path name, but maybe you should 
> exercise your option under the spec not to implement that. If someone 
> wants to open individual files separately they should either open a 
> new Store for each file, or else open a Store higher up in the 
> hierarchy and pass in relative file names. Then you could stick 100% 
> to a standardised separator and not mess with multiple separators.
>
> Anyway, that's a side issue. The bigger issue is that JavaMail tries 
> to put a consistent interface onto lots of different types of folder 
> hierarchies whether they be IMAP or directories of MBOXes or whatever. 
> I'm not convinced that users want to see different naming because of 
> the platform, anymore than they would want to when looking at IMAP 
> servers hosted on different platforms. JavaMail is not trying to be a 
> convenience veneer around local file systems, it is trying to be a 
> consistent interface across multiple mail sources.

The primary goal of the JavaMail API design for message stores was to 
model the IMAP4 specification as closely as possible. In IMAP4, you can 
have many different kinds of separators for folders; in fact, you can 
have different separators for different folders in the same store - 
that's why getSeparator is a method on Folder not Store. So clients 
should expect folder path names to be pretty opaque and specific to the 
store. The only real requirement is that you can always retrieve the 
same folder again by passing the name it returns from getFullName into 
the Store's getFolder method.

If what you want is a consistent representation of paths, JavaMail 
offers that at well, in the form of the URLName. You can retrieve a 
URLName identifying a particular folder, and you can retrieve that 
folder from the store using the URLName. The path separator in URLNames 
is always '/'.
--
Chris Burdess