Andrei, >I think there is still principal question which has to be addressed first. >The question is: will Mailet be Avalon dependant or not? > Correction: Will the MAILET compatible container recognize optional Avalon-Framework interfaces or not?
>If Mailet is clean from Avalon then logging can be removed from Mailet API, >but if Mailets will be Avalonized then logging must (more precisely may) be >in API. > v.v ? >Before this is decided no further speculations make sense. >I don't see anything against Avalonization of Mailets. >What is the bottom line of this discussion since James runs on the top of >Phoenix and Phoenix is on the top of Avalon? > Correction: JAMES (the reference MAILET impl) runs on top of Avalon-Phoenix. In the future, a proposition is that classes implementing the MAILET API, _may_ also implement selected interfaces from the Avalon-Framework APIm which is also part of the Avalon project. >James (like Mailet API) shall be Avalonized, or... whole James has to be >rewritten from ground up to keep it consistent with something else than >Avalon... > > So much FUD has been said about some misunderstood project called 'Avalon' which was perfectly good for years of this project, that it is now esablished as a must-avoid without ever being investigated by those running from it. _Please_ could people get their terms right. * Avalon is a project. * A-F are interfaces that are a good match for _any_ hosted comps * Phoenix is a container * JAMES is the reference impl container for the MAILET API and sits on Phoenix. -ph -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
