3 Replies Latest reply on Jun 11, 2006 3:48 PM by mikezzz

    Mail class refactoring

      I have commited a new version of the Mail class. I have moved all of the construction out into seperate static methods. I have also added tests for the messageSize. The value returned from getMessageSize() is the same as the number of bytes returned from getRawStream(). I have also added getHeaderSize() which is obviously the number of bytes in the headers. I have also added getBodySize() which is messageSize - headerSize.

      I have done some testing, it hasn't broken any of the unit tests (all though there are still some failing for other reasons) and checked SMTP and POP. I haven't tested IMAP.

      Mike.

        • 1. Re: Mail class refactoring
          acoliver

          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

            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

              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.