-
1. Re: Mail class refactoring
acoliver Jun 11, 2006 1:21 PM (in response to mikezzz)This isn't precisely right. So I broke body into mutliple parts right? So we need....
getBodySize(int)
You see... IMAP wants to tell you the size of the RFC822 body (the not mime part) as well as the whole message size. -
2. Re: Mail class refactoring
acoliver Jun 11, 2006 2:26 PM (in response to mikezzz)Moreover, do you think it makes sense to have a seperate Mail object/api for USER-written stuff vs internal use? Meaning the userapi Mail would interface and hide all of the mungy shit.
-
3. Re: Mail class refactoring
mikezzz Jun 11, 2006 3:48 PM (in response to mikezzz)I've add that, it is Mail.getBody().get(int).getSize() precaluated on creation. You will need to check that it returns what you are after. One thing is that we precalculate the size of the Mail, given that it the size will be incorrect if the code makes an ammendment to the Mail at some point after it is created, should we enforce immutabililty of Mail instances?
I am a little uncertain about the best approach. What I have just done is slightly cleaner than before, but still contains too much cruft. I think it should contain only the bare basic create methods. I.e. passing the SMTPProtocolInstance or IMAPProtocolInstance to the create method seems a little bit spagetti to me. I think designing the API for may be a little bit tricky. As we may want to do things like 'checkForLoops' before reading the body of the message. It might be necessary to pass in a callback object so that we can inject logic part way through the process (e.g. onHeader, onHeadersComplete, onMimePart, etc..).
Putting this logic into/hiding it behind the User API could be a good idea. If the User API was also an MBean the MailBodyManager could be injected into it and not require the caller to pass it in. I like the idea of using the same API for Mail creation internally that we expose to developers, it has a nice consistent and modular feel about it.
I am interesting on hearing other peoples' thoughts on this.
Mike.