How will you send new mails from a Mailet?
I don't. I put the mails on different queues.
Here is the current services looked up from our bundled mailets: AbstractStorageQuota: MailServer / UserStore
We haven't implemented quotas yet (this release) but these will probably be a relatively simple setting more or less off of our equivilent of MailetContext
ToRepository: Store (just needs to write a MailRepository) RemoteDelivery: Store (just needs to read/write a SpoolRepository) FromRepository: Store (just needs to read a MailRepository)
We do not have the concept of seperate repositories for seperate purposes. We have queues to process things with and a mail store where the mail bodys go (efficient blob handling for different databases). And we have the mailbox which points to the store (headers/attributes/folder)
JDBCVirtualUserTable: DataSourceSelector JDBCListServ: DataSourceSelector JDBCAlias: DataSourceSelector BayesianAnalysisFeeder: DataSourceSelector BayesianAnalysis: DataSourceSelector
I do not care to have the mailet exposed to the structure of the datastore. In fact this may not be a datastore.
CommandListservProcessor: UsersStore CommandListservManager: UsersStore AvalonListservManager: UsersStore AvalonListserv: UsersStore
We have a UserRepository concept (really just really a list of users and passwords, next release will include roles)
As you can see we need to provide to the mailets: - datasource services
no.
- repositories (read/write)
not yet sure how to genericize as a concept
- usersstore (authentication/mailing list management)
yes.
You probably missed how James works. Your proposal LOCAL/OUTGOING is too much limited. I could agree that we only need 1 interface (Currently you can create a spoolrepository from a mailrepository by adding a wrapper that add the accept services). I would also add more filters capabilities to the current MailRepository interface or we will never gets performance.
I haven't looked at in in a few years (inititally I was going to work on JAMES, but decided I couldn't accompish what I wanted). I'll download new mailet stuff today.
Describe filters?
We can easily use Mail priority headers of use multiple spoolers with different priorities provided by the container. I already use multiple spooler in my james so to have different queue with different priorities and I move mails around via a ToSpoolRepository mailet. IMHO there is no need of "priority" concept in the Mailets API: you can simulate this behaviour with a good configuration and current services).
So "SpoolRepository" is essentially a named queue?
Well the container MUST catch the static exception. I'll agree with the use of a Runtime exception when you provide an example where the container needs to NOT CATCH the MailetException.
This is a potential bikeshed and is unimportant, nevermind. You either think the system should throw checked exceptions or you do not. However, its not a big enough issue to me (like brackets should go on the same line so that your code is more compact and easier to read rather then the second line) to warrant further discussion. I can live with one checked exception that I always catch and rethrow as a rt exception.
I would use a Stream instead of the MimeMessage, leaving to specific mailets the MimeMessage creation work. We should probably provide a way to cache the MimeMessage associated with a mail stream. And what about MIME4J?
Okay. What about it?
IMHO a generic ConfigurationRepository will never perform enough or will be never flexible enough. I would limit our effort in providing a container managed DataSources (JNDI lookup as in J2EE?)
That doesn't parse for me. I don't want it to be all that flexible. I want it to be portable. I do not want mailets to be exposed to the underlying datasource because that is not as portable, dictates schema, and requires repetitive configuration (giving sql statements as config?). I do want mailets to be able to store data in a generic fashion. For us ConfigurationRepository is likely a limited wrapper around a Hibernate session ;-).
-Andy
Stefano
-- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
