> So lets start a discussion about making mailet portable and 
> serve multiple mail servers, yet not hamper performance.  It 
> is my thought that Mailet 2.0 should not reqire compatibility 
> with Mailet 1.0 (because that limits the field to JAMES since 
> there are parts of Mailet that do not take portability 
> concerns into acount and frankly I don't want to implement 
> them if it makes me change the logical structure of JBMS). 
> Controversially, I would like MailetAPI to not be bound to 
> JavaMail as that will mean I will need to support two 
> parallel APIs since we will need to abandon JavaMail 
> internally (meaning also for mailets) for performance reasons 
> and to better pull off IMAP.

I almost agree on this.

> Perhaps I do not understand but I would like to see the removal of:
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#bounce(org.apache.mailet.Mail,%20java.lang.String)
> it is unclear (bounce for a single user?  The entire mail?) 
> I'd like to hear suggestions no how to replace it to allow:
> 
> 1. Additional processing (other mailets might log things 
> gather statistics, etc) 2. Sub-Bouncing (which user, etc)
> 
> I would like to see the removal of:

First of all you should download mailets from the 2.2.0 or from the current
trunk.
The ones you are referring to are old.

> http://james.apache.org/mailet/org/apache/mailet/Datasource.html

Does no more exists.

> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#isDatasourceProvider()
> and
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#getDatasource(java.lang.String)

Neither exists.

> These are neither portable or schema independent 
> (ultimately).  They can be replaced by more generic interfaces.
> 
> I would like to see:
> 
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#sendMail(org.apache.mailet.Mail)
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#sendMail(org.apache.mailet.MailAddress,%20java.util.Coll
> ection,%20javax.mail.internet.MimeMessage)
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#sendMail(org.apache.mailet.MailAddress,%20java.util.Coll
> ection,%20javax.mail.internet.MimeMessage,%20java.lang.String)
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#sendMail(javax.mail.internet.MimeMessage)

All 4 existing in the current mailets.

> I'd like to see:
> 
> http://james.apache.org/mailet/org/apache/mailet/MailRepository.html
> 
> understand the concept of Folders (which should themselves 
> have attributes)

There is no MailRepository in the current Mailets, we should discuss how to
reintroduce it and what we precisely need.
I'm planning to create a report with services used via avalon lookup by
current james mailet to resolve issues not resolvable via API so we have a
scenario to think about.

> I'd like to see:
> 
> http://james.apache.org/mailet/org/apache/mailet/MailRepositor
> y.html#lock(java.lang.String)
> 
> throw LockAqusitionException (documented runtime exception)
> 
> and 
> http://james.apache.org/mailet/org/apache/mailet/MailRepository.html
> offer the "boolean supportsLock()" or possibly this should be 
> on the folder.
> 
> I would like to see (though it is possible that I misundersatnd its
> function)
> http://james.apache.org/mailet/org/apache/mailet/SpoolRepository.html
> dropped as it doesn't promote portability (it dictates that 
> hte mail server must queue and work like JAMES)...
> 
> and replaced with something similar to
> 
> MailetRepository.getQueue(Queue.LOCAL).add(Mail);
> MailetRepository.getQueue(Queue.OUTGOING).add(Mail);
> MailetRepository.getQueue(Queue.OUTGOING).add(Mail,
> Queue.PRIORITY_IMMEDIATE);

Mail and Spool repositories are no more part of the current apis.
BTW I don't agree with the concept of named queue (Queue.LOCAL,
Queue.OUTGOING).
We never spoke of Priorities: can you elaborate on this?

> I would like to see:
> 
> http://james.apache.org/mailet/org/apache/mailet/MailetException.html
> 
> extend
> 
> RuntimeException.

I think we should vote about this.
Can you provade a sample usage where this change is useful?
Shouldn't the Mailets run inside a container? Can't you catch the
MailetException and rethrow a RuntimeException?

> I would like to see the bindings of
> http://james.apache.org/mailet/org/apache/mailet/Mail.html to
> javax.mail.* broken.  

Currently the Mail interface has the getMessage and setMessage that are
MimeMessages: how would you like to handle this?

> JavaMail continues to be broken 
> (especially with regards to IMAP and its reliance on JAF and 
> its MegaSynchroization
> [http://www.jboss.org/index.html?module=bb&op=viewtopic&t=6779
> 1 only some of the discussion/issues caputred]) and we'll 
> likely not include it in the final release of JBMS 1.0.
> 
> I'd like to see the contract for this:
> http://james.apache.org/mailet/org/apache/mailet/MailetContext
> .html#getMailServers(java.lang.String)
> 
> explained.  When should a mail server be aware of other mail 
> servers via this method?

This is a method that return the full list of IP of the MX servers for the
given domain.
It is currently used by a few mailets that done a lookup to identify fake
sender domains.

> I'd like to see a way to locate "relay servers" meaning those 
> that it is okay to relay to regardless of authentication.  As 
> well as some embodyment of Policy and encrption status 
> (meaning require authentication, require authorization, 
> require TLS, SSL, and isEncrypted etc)..

Where exacly in the Mailet API you would like to see this services?

> I'd like to see the existence of ConfigurationRepository 
> which allows mailets to generically store/locate values 
> (statistics, etc)
> 
> ConfigurationRepository.find(Class class, key); 
> ConfigurationRepository.create(Object, key); 
> ConfigurationRepository.delete(Object, key); 
> ConfigurationRepository.update(Object, key);

Can you bring an example usage?
Is the configurationRepository  unique per Mail/Mailet/MailetContext ?

> I would like to see the concept of MailConstructor Mailets.  
> Meaning most of these mails assume the mail has already been 
> created, I would like to be able to use mailets to handle the 
> incoming stream.

Again I need an example.

Stefano

Reply via email to