Stefano Bagnara wrote:
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.
cool
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.
Ah I see. I will do so.
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.
excellent
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.
sorry I meant I'd like to see them removed.
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.
That's too bad. We actually have a very similar concept. I'm not yet
100% how to pull off a generic version of our concept of essentially
"MailRepository" and "BodyManager" (slightly different names) as We
stream the body direct to the database and hte mail repos has a pointer
to the mail. (result: No OOME or crazy GC stuff goes on)
That would be good.
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?
This is something Postfix and other MS have. You know how obnoxious
poeple always mark their messages as "important" or "very important" --
some mail servers have rules that result in those being sent in a thread
rather than queued. We'll probably need this for some mailets
(mailisteners for us ATM).
The "named queue" isn't really a "name" so much as a distinction between
mails that are queued to be processed to go out or queued to be sent in.
Out mail listener chain is called from the data command and then
queues mails. Shortly we'll have another chain called from the actual
queue processor. What makes sense to you as a designation to send mails
to local users or external?
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?
a container can catch a typed runtime exception. Sometimes it is useful
to run mailets inside of other mailets. As a whole many java developers
think Microsoft was right to drop checked exceptions from
Java3^M^M^M^M^MC#. I'm not so dead set but prefer not to deal with them
at the system level.
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?
Directly handle the pieces and mime stuff. We are investigating
switching to Ristretto (http://columba.sourceforge.net/). I'm
suggesting incorporating a similar interface and not Ristretto itself
(thus we can use Risretto under the covers if we like). This would be
more appropriate for efficient MIME altogether (though I'm admittedly
slightly removed from some of the IMAP/MIME crap this is the consensus
in our little group).
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.
Ahh okay. That is fine. I thought it for other local servers...maybe I
didn't read it clearly.
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 dunno, off of the MailetContext would be fine. Though I kind of
prefer something like MailetContext.getServer() as constructing global
information into the MC could be weighty.
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 ?
Baeysian filters, HAM, statistics keepers..
Good point. Get from MC but specific instance issued per mailet class
or config'd instance:
MC.getConfigurationRepository(); //gives a CR for THIS mailet others
will get an instance specific to them
My Baeysian filter thingy might stick in/get its pattern crap.
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.
Actually coming to think of it these should probably stay mail server
specific. A generic interface may not be useful. Disregard.
The idea is to use basically a derivative of our MailListeners to
construct the initial mail object. However on further thought it
probably makes little sense to standardize an interface for that.
-Andy
Stefano
