[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Classpathx-javamail] Rework of mbox provider
From: |
Chris Burdess |
Subject: |
Re: [Classpathx-javamail] Rework of mbox provider |
Date: |
Thu, 28 Apr 2005 07:43:48 +0100 |
Countach 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.
You misunderstand me: when I say specific to the store, I mean to the
instance of the store not the Store implementation.
In one IMAP store you might have folders called
INBOX/Saved/January
#news/comp.lang.java
Note that "java" is the folder name here with 3 ancestors. You can mix
and match different separators even in the same 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.
I agree! But this requirement fails when the store (aka directory) is
moved to a different platform.
In which case it is not the same store.
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.
You're partially right, but getURLName should also yield a pathname
relative to the root of the hierarchy. Neither of these is currently
the case with the mbox folder, but I will correct both.
--
Chris Burdess
- [Classpathx-javamail] Rework of mbox provider, Chris Burdess, 2005/04/21
- Re: [Classpathx-javamail] Rework of mbox provider, Countach, 2005/04/25
- Re: [Classpathx-javamail] Rework of mbox provider, Chris Burdess, 2005/04/26
- Re: [Classpathx-javamail] Rework of mbox provider, Countach, 2005/04/26
- Re: [Classpathx-javamail] Rework of mbox provider, Chris Burdess, 2005/04/27
- Re: [Classpathx-javamail] Rework of mbox provider, Countach, 2005/04/27
- Re: [Classpathx-javamail] Rework of mbox provider,
Chris Burdess <=
- Re: [Classpathx-javamail] Rework of mbox provider, Countach, 2005/04/28
- Re: [Classpathx-javamail] Rework of mbox provider, Chris Burdess, 2005/04/28
- Re: [Classpathx-javamail] Rework of mbox provider, Countach, 2005/04/28