Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 52517 invoked by uid 500); 8 Aug 2003 17:17:45 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 52497 invoked from network); 8 Aug 2003 17:17:45 -0000 Received: from dsl-217-155-97-60.zen.co.uk (HELO dsl-217-155-97-61.zen.co.uk) (217.155.97.60) by daedalus.apache.org with SMTP; 8 Aug 2003 17:17:45 -0000 Received: from apple.air.bandlem.com ([10.0.1.20] helo=bandlem.com) by dsl-217-155-97-61.zen.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 19lAs8-0006Ju-00 for ; Fri, 08 Aug 2003 18:17:48 +0100 Date: Fri, 8 Aug 2003 18:18:27 +0100 Subject: Re: [JavaMail] Re: Geronimo standard Sun-API jars Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Alex Blewitt To: geronimo-dev@incubator.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <52FB8908-C9C4-11D7-8489-0003934D3EA4@bandlem.com> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > The problem is that there is a lot of code related to Mime parsing and > Address validation needed to conform to the RFC's in javaMail, there > are a > lot of mail RFC's (http://james.apache.org/rfclist.html) and they would > require a lot of work to re-implement. They aren't a requirement of JavaMail; they are a requirement of SMTP/MIME and related RFCs. It just so happens that JavaMail also uses them. > I'd be very wary about starting down the road of an Apache clone of > javaMail > unless it really offers serious advantages. o Easier API to use to generate/send mails o Less global configuration settings (JavaMail uses global system properties) o Conformant JavaBeans representation of MimeMessage o Use of Mail.getAttachment() to facilitate attachments, rather than presenting the low-level layer of how they are transmitted in MIME Multipart formats > Bearing in mind that any clone of javaMail would have to offer pretty > much > interchangeable behaviour with the official product, particularly if > it has > to pass tests, the issue of implementing the Store and Transport > interfaces > is where we should start, and quite probably end too. I've got an implementation of Transport kicking around from before that I can donate to the project, and I'm more than willing to give an implementation of JavaMail ago. But since I don't have access to the CVS repositories for dumping implementations, I'll have to send it as a pretty big patch file :-) Alex.