bloody Gmail, 2/3 of my last message were missing :-( I've tried to reproduce it here, but its never the same when you have to try to re-write something from memory.
On 11/6/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
Is there any way to concretely to eliminate java.sql.Connection getConnection()?
Yes, it need only be visible in implementations, I don't want there to be any use mandated.
I don't think mailets need access to general structures like mailboxes via SQL connections. I do see them needing general use stores.
exactly, and in general we can allow the specification of arbitrary services and leave db or non-db implementation as that, an implementation detail. "want to use mailet X? first you must install service Y. server-Y needs an rdbms but you can use desktop-Y which peforms less well but uses xml files" <snip>
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.
Thats a good thought, I'll try it out, normalise the relationships between user, local-part, domain and repository.
I did not see processor or spool in org.apache.mailet and thus haven't really evaluated them as generic constructs.
Processor is really just a mailet, if you replace it with Mailet you get the possibility of having an arbitrarily deep tree of nested mailets, which I kind of like. Spool is just a specialised repository which is FIFO and normally empty.
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.
Yeah, but consider this, map POP3 IP listener addresses to domains and you can have two "andy" accounts on the same instance, but they will be discrete. d.
