Sorry, I should have sent this to -dev...
---------- Forwarded message ---------- Date: Fri, 9 Jan 2004 10:51:15 -0800 (PST) From: Martin Cooper <[EMAIL PROTECTED]> To: Jakarta Commons Users List <[EMAIL PROTECTED]> Subject: Commons Multipart, anyone? (was: Re: [net] Why use Net for SMTP?) On Fri, 9 Jan 2004, Mark R. Diggory wrote: > > > Daniel F. Savarese wrote: > > > > > I think that impression may be based on a different expectation of what > > the API was originally intended to do. I know you're not looking for > > an explanation, but for the benefit of onlookiers ... > > Returning a writer was an efficient way of bypassing Java's terrible > > (at the time) memory management and allowing large amounts of data > > (i.e., many megabytes as in attachments) to be written to a stream without > > buffering it all. The package was never intended to model email messages > > or provide all the hooks of JAF, hence the C-like approach in this case of > > "here's a stream, write your data to it." It's clear that people who look > > at the library today want higher level functionality and that will have to > > be accommodated in any future redesign. Also, with GHz processors, > > GB memories, and fast JITs, better OO designs that were woefully inefficient > > in JDK 1.1 days (e.g., JavaMail 1.0) are quite fast today. Maybe the smtp > > package will simply have to be removed in 2.0 for lack of demand, > > insufficient functionality, and by virtue of being obsolete. Regardless, > > anyone who uses the library (and even anyone who doesn't) who has criticisms > > of the API should not hesitate to offer their criticisms. You won't be > > hurting anyone's feelings. If the library is going to keep up with the > > times and be used for another seven years, it's got to be overhauled. > > I really like the model for handling multipart content currently > maintained in HttpClients MultipartPost method. For the most part, your > going to either have content in memory or in a file on the filesystem, > generically wrapping any "Part" including references to a file in the > filesystem allows one not to have to put it into memory and still > process it into the Writer/Stream without the user really needing to > manage it. > > http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/methods/MultipartPostMethod.html > http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/methods/multipart/FilePart.html > > If there is a consideration to work on the SMTP implementation. This is > an excellent approach to consider. > > Are Mutlipart Http Posts and Multipart SMPT messages encoded the same > way or is the naming just a coincidence? They are both multipart MIME, but the specific MIME types are different. I think a Commons Multipart component would be very interesting. We already have multipart creation code in Commons HttpClient, and multipart parsing code in Commons FileUpload. Breaking these out into something like a Commons Multipart that could be used by both - and potentially by Commons Net in more comprehensive mail handling - would be great. I would be +1 on creating a Commons Multipart component, meaning that I am willing to put in some time and effort, if other people are interested in collaborating on such a beast. Anyone else? -- Martin Cooper > > > -Mark > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
