306898 - Grendel dependence on JavaMail provider implementations

Status: RESOLVED WONTFIX

(Grendel Graveyard :: Protocols, enhancement)

Description

[Kieran Maclean]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: 

To make use of many of the features of a JavaMail provider implementation, other
than the basic it is necessary to provide implementation dependent options.

This leads to the problem that Grendel may become dependent on a particular
implementation of a JavaMail provider.
This would lead to problems when integrating new JavaMail providers or changing
JavaMail provider.

How should Grendel handle different implementations of JavaMail providers?
For instance the sun implementations use separate provider classes for SSL and
non SSL connections where as the GNU JavaMail implementation uses a Session
property to enable SSL connections.

One possibility is that at the point of connection to the service the Account
settings object is asked to provide the relevant details for the connection,
including the name of the Provider to try biased on some integration of the
javamail.provider file via the Global Session object.

Another is to add a JavaMail implementation abstraction layer to allow the
properties to be automatically determined and the correct javax.mail.Store
instance biased on either the javamail.provider file or some other architecture
to attempt to detect the correct provider to return replacing the
javamail.provider structure.

It may be worth noting that the caching is planned to be implemented as a
"transparent" JavaMail store. ( The Cache is used as though it was the underling
JavaMail store, but the messages and folders are cached automatically. )

Any other suggestions are welcome.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Kieran Maclean]

Arranging bug dependences and assignments for code patches.

Comment 2

[Matthias Versen [:Matti]]

marking wontfix as grendel is removed from cvs