Is there is change that you would want to make to the proposed API, or are you raising a procedural issue? I would like to see the functionality integrated.
My notes below on the actual changes, but I think we need to discuss changes before committing them to the mailet API (v2 or v3). I think we've discussed and agreed for v3, but not discussed adequately for v2.
There are two changes to the Mailet API that have been proposed for v2.2 that are compatible:
1 - mail attributes
Just adds to the API. It's something everyone wants, it doesn't create backwards compatibility. Seems reasonable to me. Maybe make a bigger version # jump, but already this is for v2.2 (not 2.1.x)
2 - deprecating setSender/getSender in favor
of setReversePath/getReversePath
I like this, but for the reason nobody discusses... it focuses the mailet API on handling SMTP traffic, and not trying to be some big messaging scope-creep project.
Again, as it's additive, I don't think it's a big issue.
Maybe the better solution is to put the mailet API on a separate release schedule, so it's clear that James 2.1.x implements mailet API 1.0 and James 2.2 implements mailet API 1.1.
I'm fine with reving the version to Mailet API v2.something or some other procedural change. That's similar to why we've proposed calling the next version 2.2.0, instead of 2.1.4.
I think this is the first revision to the mailet API (aside from v3 changes) since its release many years ago. And as it's minor, I would move it to 1.1 as opposed to using the Microsoft versioning formula:
#foreach (product in suite) product.version = max(product.version in suite) #end
:)
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
