You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mailet-api@james.apache.org by ac...@apache.org on 2005/08/19 21:05:19 UTC
Remove Datasource interface
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.
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:
http://james.apache.org/mailet/org/apache/mailet/Datasource.html
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)
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.Collection,%20javax.mail.internet.MimeMessage)
http://james.apache.org/mailet/org/apache/mailet/MailetContext.html#sendMail(org.apache.mailet.MailAddress,%20java.util.Collection,%20javax.mail.internet.MimeMessage,%20java.lang.String)
http://james.apache.org/mailet/org/apache/mailet/MailetContext.html#sendMail(javax.mail.internet.MimeMessage)
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)
I'd like to see:
http://james.apache.org/mailet/org/apache/mailet/MailRepository.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);
I would like to see:
http://james.apache.org/mailet/org/apache/mailet/MailetException.html
extend
RuntimeException.
I would like to see the bindings of
http://james.apache.org/mailet/org/apache/mailet/Mail.html to
javax.mail.* broken. 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=67791 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?
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)..
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);
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.
Thoughts?
--
Andrew C. Oliver
Lead developer, JBoss Mail Server
JBoss, Inc.
Re: Remove Datasource interface
Posted by ac...@jboss.org.
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
>
>
Re: Remove Datasource interface
Posted by Stefano Bagnara <ap...@bago.org>.
> 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
RE: Remove Datasource interface
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andrew and Stefano,
Replies to your various messages below.
ACO wrote:
> So lets start a discussion about making mailet portable and serve
> multiple mail servers, yet not hamper performance.
Fine. :-)
> 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.
As an aside, can you elaborate on the problems, and why they cannot be resolved by writing a better implementation? Server side IMAP isn't supported at all by JavaMail, so I'm not sure what problem you're seeing, but I'll guess that it has to do with the store interfaces.
I'm not sure that we want to use JavaMail, but it is the only standard that we have at the moment if we want the Mailet API to have access to repositories. Otherwise we need to create our own.
Most mailets don't need access to a repository notion, and simply process the message handed to them a la a message bean. We still need repository support for at least a class of mailets, but we could move that API to the MailetContext or make it a discoverable service.
> I would like to see the removal of
> MailetContext.html#bounce
Bounce is now handled within the the pipeline, but I'm not sure that we really don't want mailets to have no access to the capability. There ought to be some way for them to tell the context that the message should be bounced, even though the implementation might go back into the pipeline to a bounce mailet.
> 1. Additional processing (other mailets might log things
> gather statistics, etc)
We need to expose discoverable services to mailets, and they can see which ones are available in their context.
> I would like to see the removal of:
> http://james.apache.org/mailet/org/apache/mailet/Datasource.html
The data source and repository related methods don't exist, and never did They were an experimental thing in a never deployed branch of JAMES. The web site has this experimental stuff, and we need to rebuild it with the real API. In respect to repositories, we need to redesign both mail and user repositories.
> I would like to see the bindings of
> http://james.apache.org/mailet/org/apache/mailet/Mail.html to
> javax.mail.* broken.
Again, JavaMail is *the* standard. We can try to convince Sun to improve it, and we have an alternative (MIME4J) that provides streaming over mail. I don't believe that removing JavaMail makes sense, but we can loosen dependency.
For most mailets, we just need access to headers and body content, which MIME4J can do quite nicely. For storing things, we certainly don't want the JavaMail stuff. But for editing messages, JavaMail comes in handy.
Ristretto looks interesting, too, but you should checkout our MIME4J code. :-)
> I'd like to see a way to locate "relay servers" meaning those that it is
> okay to relay to regardless of authentication.
I disagree. That is something that the relay mailets should handle, and be part of their configuration.
> I'd like to see the existence of ConfigurationRepository which allows
> mailets to generically store/locate values (statistics, etc)
I'd like to see us switch to Jakarta Commons Configuration, and get away from the non-standard, read-only, Avalon stuff. There are several implementations of Commons Configuration that should support writable properties.
I disagree with mis-use of RuntimeExceptions, having had to debug too many (over)uses of that approach. Stefano and I agree on this, and I'm glad to see that we can continue in this way.
Stefano wrote:
> 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.
Close. JNDI (the standard) lookup. Avalon APIs are to be removed from JAMES. Glad to see that you also want to make more use of JNDI.
More things can be exposed as discoverable services, including the ability to post messages into the system.
--- Noel