Stefano Bagnara wrote:
An alternative is (if we really care about switching implementations)
is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl
we could code share (as you say), or whatever's appropriate.
There could be intersections. There are algorithms needed for IMAP
Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create interfaces that
mirror the
Joachim Draeger wrote:
Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create
Joachim Draeger wrote:
- MessageKey created while storing, and not userprovided.
This would make implementation of existing standard a lot easier. Are
there disadvantages? When I store the same message into different
repositories I've to care about the repository keys myself when I want
Mail/Spool/Message repositories refactoring
---
Key: JAMES-521
URL: http://issues.apache.org/jira/browse/JAMES-521
Project: James
Type: Task
Components: James Core, MailStore MailRepository
Reporter: Stefano Bagnara
Stefano Bagnara (JIRA) schrieb:
- Introduce a MessageRepository interface for MimeMessages (not Mail objects)
to replace the current MailRepository usage: we could even use JavaMail
Store/Folders but maybe we should have our own interface and a wrapper.
The biggest design deficiency of
On 6/2/06, Joachim Draeger [EMAIL PROTECTED] wrote:
The biggest design deficiency of Javamail is the lack of interfaces. That's why
using javamail means being limited in hierarchy, and being unable to completely
replace implementations.
This is an interesting point... should we create
