Noel J. Bergman wrote:
Yeah exactly, this gets back to my big mounting strategy... it allows to configure repositories more flexibly, so it's easier to wrap JavaMail (POP3, IMAP) with a Mail repository implementation.Serge,I agree with your concern regarding whether Received includes the RCPT TO info. Please note that I had originally proposed specifying the address that would be used for the new Mail. Danny wanted more automatic support and mentioned Received. I think that Received is good, but raised the question regarding the fragility of that contract, and so we've gone circle and come back to Received providing a default, and a configuration item providing a fallback. Personally, I'd like to eventually have much more of fetchmail's range of configuration items, where it makes sense, but Danny is right to push for simplicity in terms of what is required. If someone (e.g., Serge Sozonoff) is really interested in enhancing FetchPOP, I am fairly sure that Eric would be happy to explain any design rationale behind things that don't appear documented on the fetchmail web site (http://www.tuxedo.org/~esr/fetchmail/index.html). Personally, I'm not interested in demuxing enterprise e-mail from a single mailbox, but I can see how one might want to recreate RCPT TO addresses such as mailing lists or other. If I were to use FetchPOP to migrate e-mail from my personal main mailbox to James, I believe that I'd have a lot to do to recreate the information that I currently use for client filtering.a. the remote mailbox (pop3 or imap4) is mounted somewhere on the mail repository virtual file system.Interesting idea. Can't JavaMail do that for us, since we'd be using it as a client talking to a server?
I think once I get the time I'll probably create a branch to show how this would work since there seems resistance mainly because of the newness of the idea. Or maybe just some conf file and related java code to explain it better.
Judging from the CVS commits, I think the Mail Repository is already moved over to the mailet API, and I don't really expect to make many changes. I actually think it works just fine with the children support and storing/getting Mail objects. We might separate spool repository, but I'm not too worried about that. We'll potentially have to change the implementations depending on what we do with Mail objects (namely adding attributes), and my mounting change would only really change how lookups function (I believe).I already plan to let us mount pop3 and imap mailboxes in the virtual file system (assuming everyone likes this)I think that now that Danny has started pushing the Mailet API v3 interfaces, the main things that need immediate attention are the Mail and User repository models. I am not sure that everyone sees things the same way, yet.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
