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 Tue, 11 Jun 2002 16:55:55 GMT
Noel J. Bergman wrote:
> Insufficient.  Mailets should be portable.  We can't simply wash our hands
> of a functional area and say "it isn't Mailet behavior, so we just won't
> deal with it."  A Mailet needs to use a service.  We need to provide a
> common means to do so, or we effectively mandate platform-dependence.

I've written a lot of servlets that needed tweaking from one servlet 
container to another.  The goal of the API is not 100% platform 
independence in every case so much as a baseline that multiple 
containers can implement.  You can always write code that can't be ported.

How do you reconsile the following... James provides POP3 access.  Other 
mail servers will not have any local repository, simply functioning as a 
mail processor/gateway.  If the mailet API specifies how to interact 
with user inboxes, then what is the other mail server going to do since 
it does not support the concept?  On the other hand, if the mailet API 
does not support user inboxes, then you're going to have a mailet (or a 
few) that will need capabilities outside what the mailet provides that 
is tailored to James.

As the mailet API is focused on mail processing, I think it's an API 
that could be used by SMTP-only servers.  So, we made the decision a 
while ago that we wouldn't add user or message repository to the mailet API.

> A Mailet may CHOOSE another way, but that means it will be
> platform-dependent.  Fine, but we must still support platform-independence.
> It is one thing to say that I can roll my own, but quite another to say that
> I MUST.  How do we ensure both platform independence and proper behavior if
> everyone rolls their own?  The platform neutral stance is to EITHER have
> logging in the Mailet API, or say that if a container wants to providing
> logging to platform-independent mailets then it SHALL use LogEnabled.
> Otherwise you have software anarchy.

We have a servletContext.log() method.  If mailet authors need more, 
they can figure out the best way to do for their situation. 
java.util.logging does it with static methods (I hear the boo'ing 
already).  Instead as we're using James built on this great Avalon 
framework, I'll have some alternate way of logging.  There may be a 
failing in the James/Avalon-framework documentation or offering at this 
point if it can't expose a way to log, but I don't see why it's the 
mailet API's fault that there is software anarchy.  Frankly, I don't 
feel smart enough to know what the best solution is, so I don't want to 
add logging to the mailet API and impose my technical opinions on other 
mailet developers.  I don't think it's appropriate to say SHALL.

> No.  Not a strong enough statement.  If JAMES does it, then it is James
> specific.  We either provide a portable Mailet specification, or just bag
> the whole independent API idea, and say that James IS the Mailet SDK.  Which
> is NOT what we want to say.  It is not JAMES that does it, but Mailet
> Containers do it, of which James is the reference implementation.  

How about we separate reference implementation mailets from James 
mailets?  This could clarify what other mailet compliant containers 
would need to run.

> Absolutely NO!  From where do they get this "default Logger", hmmm?  LogKit?
> System.err.println?  Vendor specific API?  Log4J?  Do you see my point?
> This is anarchy.

Or freedom. :)  Seriously, if someone had come up with an API that 
solved every need, then there wouldn't be so many offerings.

> James is A Mailet Container.  You need to mandate that this as common
> behavior for A Mailet Container, not just James.  Else, you are wrong.  It
> punts.  It says that "oh, well we don't know how to do it, so here is one
> way, but don't count on it; it isn't our problem."

Yes, exactly.  Well put.

> Clean?  Here is clean:
>    interface Mailet { public void service(Mail) throws Exception }

I bet I would win a dripping-sarcasm competition if we wanted to go down 
that road.  I don't think that was Darrell's point.

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