> 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
I will do that by adding MessageRepositories soon and merge Mail/Spool Repositories into a single entity. MessageRepositories are for Messages, Mail/Spool repositories are for Envelopes (containing messages). Eventually Mail/Spool repositories could make use of MessageRepositories for the message storage purpose. > on point 2 please explain this in more detail, 1st what is > required and why, 2nd what is your proposal, (I assume have one!). 2) recipients attribute: Recipient to be an object having one main attribute (the mail address) but adding to it the "attributes" in a similar way we use attributes for the Mail object. This way I could add an "OriginalRecipient" attribute with "rfc822;[EMAIL PROTECTED]" value and a "DSN-NotifyRequest" attribute with the value "SUCCESS,DELAY" when a client issue the "RCPT TO: <[EMAIL PROTECTED]> ORCPT=rfc822;[EMAIL PROTECTED] NOTIFY=SUCCESS,DELAY". This is the only clean way to achieve ESMTP-DSN support and other ESMTP extensions. This will need changes in repositories (currently our jdbc mail/spool repositories expects Recipients to be just an email address. > 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. Exactly: we need to be sure every operation is done via Context so that we can safely track what happens. > 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. We will talk again about destinations in future: I'm plannin changes in repositories and repository selection, virtual repository maps and other possible new features that could help us understanding the easiest way to implement my idea of "destinations". One of the possibilities is to use sourcerouting informations to let mailets to add hints on destinations. BTW we've a lot to do before this, so I prefer to do now something else, and to discuss destinations when we have finished implementing the other more defined tasks. Stefano
