On 11/5/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
It has been awhile since I looked at this but portability is also limited anywhere that the underlying storage medium (IE database connection) is exposed. A limited interface should be provided for this.
Agree. The API should be abstract and agnostic about implementations. presenting an abstract model of the entities involved in email processing, and some rules to facilitate portability.
I have more questions on aliasing and default inbox etc than I have answers.
I have some opinions but not answers, there are plenty of people who might disagree. Basically I think we need to be mroe rigorous in our analysis of users, accounts and mail storage. A user object should be able to inform its context of the storage location, and specific rules about routing. Possibly also allowing individual processing, e.g. per-account anti-spam settings. The mapping of aliases and forwarding should be by a reverse lookup wich resolves a real user. The context should have a model of storage and processing entities from the point of view of deployment and management, but preferably not including any functions which are required to complete normal handling of users and mail. Handling of users and mail should be contained wholly in entities which are modelled as process components (mail, matcher, mailet, processor, spool et al)
For SMTP, the root mailbox is looked up and then navigated to a subfolder called INBOX.
I agree with this, and have made some experiments in virtual hosting in which James can be configured to accept and handle mail for multiple "roots" in SMTP and POP3. Sadly I never commited them and they're now lost. Hopefully I can recreate this here because I think it is in scope of mailet refactorings as it also removes the nasty "special globals" which not only reduce portability but also enforce assumptions which are not valid. (i.e. it assumes that only one set of inboxes are required)
So I can see a more direct "getDefaultInbox" and "getDefaultOutbox" being reasonable.
I think thats only reasonable if you contextualise that with a User or a domain. Otherwise it is an untested assumption that the concept of a default is supportable, or that the constraints imposed by enforcing a default are reasonable. You might find that it is actually safer to run without a default, and to error if a configured mailbox can't be resolved. I don't know, its just a discussion point. Thanks Andy, interesting points. d.
