Hi All, I am following this thread because I like the dramaturgy of it ;) (all this discordance and unpoliteness). After Noel admitted that he was just exercising a test starting this thread, there seems to be just complete consensus about that there is no extension of the Mailet API needed. On the other hand you do not really concentrate on the question whether JAMES will introspect the Mailets and serve them with the applicable Objects (which easily could be implemented as an option). So what are you argueing about????
But on the question whether to expect other containers on supporting the avalon FRAMEWORK interfaces I would like to bring in my opinion: Maybe you know alternative Mailet containers, but I don't. Maybe you hope to spread the Mailet API as a standard, but I won't. Thus, this question is of no importance in my opinion. But if you still are trying to spread the API, keep the expectations on the other containers low. (You can not force them to introspect the Mailet objects anyway.) I like James (I am using it). I am not using its logging since we have logging facilities of our own and the mailprocessing part is the smaller one of my application. In this way staying portable with other containers ;) I am still not expecting to switch in the next couple of decades. Yours, Marcus -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
