Danny Angus wrote:
On 11/5/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
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.
Is there any way to concretely to eliminate java.sql.Connection
getConnection()?
There are standards that can be built on (JPA for instance) but they
tend to potentially
be too cumbersome (JPA/EJB3 have a pretty heady performance cost for
this type of
storage and we may migrate away from them for a lot of things, its
already pluggable).
We don't guarantee that we use a database for storage. Right now it is
our only working
implementation but I see that changing.
I don't see us using this abstraction in the core of "the yet to be
renamed mail server" (TYTBRMS) as
it is hard to do a good abstraction here that is both lightweight and
per formant especially with things
that resemble joins.
That being said...
I don't think mailets need access to general structures like mailboxes
via SQL connections. I do see them
needing general use stores. If these are more than trivial (flat column
row entities), then they probably should
require a structure such as a database. However I think this should be
provided via their own configuration
(setDatasourceName() and they do their own lookup an DBMS management
outside of the mailet API with a big
astricks next to database portability [ but not mail server 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.
I kind of look at it this way:
email addresses are strings that map to a destination
For a endpoint mail server that destination is a folder
users have access to folders.
Thus:
user: andy
accesses:
andy/INBOX
address: [EMAIL PROTECTED]
receives mail to:
andy/INBOX
In fact the entire concept of a "user" is really only useful for POP and
IMAP (or similar) and
not SMTP (or similar). Except with regards to "MAIL FROM:" in which
case it is a matter of
andy having access to send mails as "[EMAIL PROTECTED]" supposing
"verify-identity" is turned
on.
I do think that a User object with general profile information is a
useful construct but don't
like marrying it to closely to addresses (even if users conceptually
think of it that way). Once I
divorced the two in my mind, virtual hosting, mail lists, and public
folders start coming together
more nicely.
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.
Yes exactly.
Handling of users and mail should be contained wholly in entities
which are modelled as process components (mail, matcher, mailet,
processor, spool et al)
I did not see processor or spool in org.apache.mailet and thus haven't
really evaluated them as
generic constructs.
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)
"multiple roots" explain that. you mean configurable? The protocols don't
really allow for this at once.
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.
I don't really agree with this because you end up having to authenticate
with "[EMAIL PROTECTED]" which
not all clients support. users are users and users are not addresses
but users have permission to send as
addresses. addresses map to destinations which are either remote paths
or local folders.
I see your point about default inbox/outbox. It is really an issue with
the suckiness of IMAP and such. For kicks
let Outlook, Entourage, Thunderbird and Mail.app all create folders.
They each create a different version of the
sent folder. Though IMAP SPECIFIES a folder called "INBOX" it is hazy
on whether INBOX is the root or INBOX is a child
of the root. They didn't see the wisdom of the same for "Sent" (or
"Sent Items" or "Outbox"). Having a way to map all
these back to one is a useful feature but maybe doesn't belong in the
mailet API specifically. Though Folder navigation
itself obviously does.
Thanks Andy, interesting points.
Same.
-Andy
d.
