Noel J. Bergman wrote: > Alternatively, we get the respository that represents that > folder, and we > store the mail without needing to make any other changes to > the API. Folder > hierarchy is a naming issue.
Is the MailetContext intended to represent 1) A facade collecting together a few operations whose actual implementations are spread across various components of the underlying MTA OR 2) A simple bridge to the underlying MTA components??? Other than the experimental changes, it seems to be uniquely (1). Adding methods that answer components is mixing in (2). Personally, I don't see that we need to do this to resolve the sub-folder issue. Supplementing the current... void storeMail(MailAddress sender, MailAddress recipient, MimeMessage msg) with... void storeMail(MailAddress sender, javax.naming.Name destination, MimeMessage msg) ...enables any storage mechanism whose locations can be specified using a JNDI Name to be used. During initialisation, a Mailet would discover what JNDI destinations are supported by the current environment. If we are heading towards JNDI anyway, why not? -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
