Re: Rework of mbox provider

Chris Burdess wrote:

> 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. 


I agree! Specific to the store. The issue is that when you access the 
store from different platform, the MBOX separators will change, whereas 
the IMAP ones won't. Thus the separator is not specific to the store at 
all, it is specific to the platform. It doesn't bother me  what wierd 
algorithm might be used to select the separator, what bothers me is that 
the separator is different when accessed on different platforms.

> 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.


I agree! But this requirement fails when the store (aka directory) is 
moved to a different platform.

> 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 '/'.


No good. The getURLName function returns the absolute pathname of the 
mbox where it happens to be mounted on this particular machine at this 
particular time.  The getFullName function on the other hand is meant to 
return the name of the folder RELATIVE to the root of the hierarchy. 
This is the string that could be potentially be platform independent if 
it was so designed.