On 19/08/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > I would like to <the cool stuff he'd like to do has been mercilessly snipped/>
Stefano, I've got a lot of thoughts on this, and some code/UML which has informed my thinking. What I don't have is too much time, so I'm asking... Please take this slowly, and separate each proposal out so that we can examine each one as you do them. Propose->discuss->comit->review. That way I would hope to be able to give you some useful feedback. But 1st of all, +1 to modelling message->envelope properly on point 2 please explain this in more detail, 1st what is required and why, 2nd what is your proposal, (I assume have one!). on point 5 we need to split it when the content changes or if the route forks, and expand it when the message is unchanged and the route is unchanged but more recipients are added. As for destinations, I'm not convinced that modelling destinations would help, it is likely to add confusion and result in more than one way to achieve a specified result. I'm +1 for encapsulating and exposing a coherent model of storage, for Mailets to use, but -1 to having destinations explicitly set in Mail's. The destination should be the result of applying a routing algorythm to the Mail, and can vary depending upon the purpose of the Mailet performing the evaluation. Destinations do not map 1:1 onto messages, even if only 1 recipient is specified, for instance mailinglists, moderation and archiving might want to silently fork or redirect messages. In summary destination is not a state a message can have. d.
