james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [Mailet API] Logging Proposal
Date Wed, 12 Jun 2002 22:12:19 GMT
Noel J. Bergman wrote:
> So, we're discussing the Mailet API, although I think that term turns out to
> be a bit of a red herring, since no on really wants to clone things into the
> Mailet API.  We are really discussing what packages are supposed to be made
> available to mailets regardless of whose mailet container is being used, and
> then how those packages are to be provided to the mailet at runtime.

I'm sorry it seemed like a red herring.  I didn't think logging belonged 
in the mailet API when we started, and I don't now... again, I'm sorry 
if this seemed like I was just throwing out a red herring.

The two changes to the mailet API that I thought might still go through 
are get/setAttribute on a Mail object, and adding name/value parameters 
to matcher configuration.

> That might work for mailet authors, but I believe that it leads to chaos for
> the poor administrator who would have no cohesive log for his/her mail
> server.  Regardless of whether a mailet gets a logging service from the
> MailetContext or through the mechanism advocated by the Avalon Frameworks
> designers, we can provide a common interface to logging, just as we can for
> the other domains you raise below.

I guess I don't see how specifying a logging API will control developers 
and reduce the administrator's chaos.  Sun and the JSR decided to 
include in every JDK from 1.4 onward with a logging API.  Avalon 
developers and log4j users still will use their own thing.  If I could 
state your objective as getting all developers to use the same logging 
API, I don't think we can do that.

>>I guess I would only suggest you take a look at the "competing"
>>solutions to mailets right now.
> Are there any?  ;-)  Not in my book.  :-)  I am not forced to be here.  I am
> here for the simple reason that James has the potential to do what I want
> better than anything else of which I'm aware.

Just FYI, off the top of my head here are other products that do what 
mailets do:
- procmail
- sieve RFC
- sendmail 8.11 and later (milters)
- JAMS http://www.kimble.easynet.co.uk/jams/ has filters
- ichabod http://sourceforge.net/projects/ichabod/ can add your own 
- Oracle's mail server supports mail process as event handling,

I'm sure there are plenty of others out there.

I list these mainly because these could implement the mailet API if they 
wanted.  These are what we originally considered as possible mailet 
containers, and I don't think that view has changed.  James is an 
"enterprise mail server" that has features beyond the mailet API.

>>Few of them have any concept of user repositories, message repositories,
>>application logging, or other enterprise mail server features.  None of
>>them really grasp the power of Java, and that's hopefully part of why
>>mailets are the right answer.
> Mind you, repositories are only available because the Avalon Frameworks are
> exposed.  MailetContext.getAttribute(String) is the all encompassing
> catch-all for getting at services, and the docs say that it is container
> specific.  If we want portable mailets that can do more than just filter the
> content of the MimeMessage and redirect processing, we need to do something
> ... which gets us to the next point.
>>But I'm not sure if we need to create new API (and especially need to
>>touch the mailet API) to support these concepts.  Maybe we can map out
>>what we need in terms of "Enterprise Mail Server Services" and find
>>existing Java APIs that fill these needs.
> I agree with this.  This is what I mean when I say that we don't necessarily
> need to expand the Mailet API (the mailet package), but rather we can
> address the issues by specifying the other packages that a Mailet container
> shall make available.  One way to do this is by adopting Avalon frameworks
> and the programming model used there.  I asked Paul about a sample container
> so that we could see what that would entail; he's agreed to do one.
> Alternatively, we could keep going the way that the API is currently
> structured, but specify a core set of services that containers need to make
> available through the MailetContext.
> The difference between those two is partially how/when the binding between
> components occurs.  As for the specific interfaces we might adopt ...

I don't quite know what to say to all these points... could you expand 
on how a mailet container would make available packages that adopt the 
Avalon framework, without incorporating the avalon framework into the 
mailet API?

>>For user repository API... well, JNDI would work, right?
> We'd have to write both some backend code, and some utilities to make life
> palatable for authors.  JNDI is not fun, and is generally massive overkill
> in the typical case.

Yeah, I get that sense too.  In my mind that leaves us with mailing 
lists implementing a mailing list interface as they need it (so no need 
for us to touch that), maybe define a user repository for mailboxes in 
your mail server...

>>Then message repository API we build as implementations of JavaMail's
>>javax.mail.Folder (actually doesn't look as irrational as you might
> I don't know enough about that package at the moment to comment.  Since that
> is your suggestion, why don't you elaborate on your idea(s).

Well, not sure what more to say... instead of the MailRepository 
interface, we use the javax.mail.Folder interface.  I'm not sure if we 
can fit the Mail specific objects in the store effectively, or if this 
is overkill or not yet.

>>Logging I think is pretty easy... JDK 1.4 is readily available,
>>or heck we're on Avalon-framework so just use that API.
>>I've really really wanted to expose the db pooling as a
> javax.sql.DataSource
>>I think the more we rely on other existing Java API, the easier it will
>>be for mailet developers to get up to speed, and ultimately the more
>>portable mailets will be.
> These exemplify what I've been saying.  The point is not changing the Mailet
> API, per se, but being willing to specify additional packages that we adopt
> to model necessary "Enterprise Mail Server Services", and make them part of
> the Mailet specification that containers must support.

To geek a bit,

mailet != Enterprise Mail Server

in fact,

mailet < Enterprise Mail Server

> The simple fact is that we cannot have a portable mailet container without
> (a) addition to the Mailet API (-1), (b) specifying other packages that
> shall be available to Mailets (+1), or (c) significantly restricting what
> mailets can do (e.g., eliminating access to users and stores) (-1).

Also, my list of all these issues were meant to show that because we're 
using JAVA means, we don't have to do this.  You pick your JDK, you get 
a core API.  You add jars, you get those libraries.

I guess I just don't get (b) because this seems to say that we "give 
permission" to use javax.sql.DataSource in mailets.  What is the benefit 
of that?

Serge Knystautas
Loki Technologies - Unstoppable Websites

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message