> Lets leave the Mailet logging, and other mailet API issues 'till after the
> release.
I wasn't planning to make any changes, other than reduce some debugging
output, until after the release. Certainly not API changes! I'm not
looking to cause a problem. :-)
As things stand, I'm done. Other than checking in some new mailet/matcher
code, I've got nothing on my plate for 2.1 release. Which is good, since
Peter wants feature freeze tomorrow. :-)
The logs are very important to me. I maintain a monitor in the upper
righthand side of my workstation watching all of the James logs in
real-time. If anything, I have added some useful logging information, e.g.,
when a socket times out now, we now log with whom it timed out. OTOH, too
much tracing information, once the code works, can mask real problems.
One thing that I really want for the next release is the ability to
dynamically configure logging. For example, if I suspect a problem in
handshaking, I want to be able to turn on debug for a protocol handler, and
then turn it off afterwards. Right how I have to reboot to affect that
change.
> There are a number of potential changes we need to discuss to the API and
> James' implementation of it.
The storage interface is the other major area that comes to mind.
> I'm prepared to review my opposition to advanced logging in the API, but
not
> right now.
I agree. API changes should all be post-2.1.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
