I agree on the Md5AwareFolderMessageStore idea.
Just a note: we should limit our discussion to the "UIDPlusFolder" and
"Javamail Store / Javamail Folder" concepts and avoid to talk about
maildir and in particular of the GPL Javamail Store maildir implementaion.
It is likely that if we support Javamail stores people will use the
maildir implementation, but we should concentrate on our usage by now. I
think your work is a good step forward in this direction.
There is not too much support of Javamail storage APIs out there, but I
know at least Grendel (http://wiki.mozilla.org/Grendel) that should
include at least a BerkleyDB based implementation in Java. IIRC they
also intended to support derby. I should check out their progresses.
If they release Grendel libs under the MPL their usage is more ASL
friedly than the GPLs.
Stefano
Joachim Draeger wrote:
Hi Stefano,
Stefano Bagnara wrote:
My opinion is that we should use reflection for that so we don't have
to introduce "imaginary.javax" packages/interfaces.
Yes, that seems to be the only practicable alternative.
quote: 'We can add the "imaginary.javax.mail.UIDPlusFolder" (or a
similar interface) to the mailet API or to a third party ASL2 licensed
project.'
That is the other possibility I had in mind, but it is obviously to
complicated.
The best of both worlds would also be to have a workaround (based on
the md5 hash hack for each message we discussed before) for stores not
implementing this "method".
I'm not sure if that would be a way. I fear that stores might break the
checksum just because they are not aware of it.
We could provide an implementation of Md5AwareFolderMessageStore and
warn people that the store has to guarantee this behavior.
Performance of this could be acceptable because it might be possible to
guess message number of requested messages by a cache and only rehash
the whole folder if that fails.
Using the Message-ID as Noel suggested in his wiki-post is problematic
because it's generated by the client. This conflicts with Postel's Law
"...be liberal in what you accept from others.."
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
