Sorry for the late reply, I'm lagging behind on the digest. In message <[EMAIL PROTECTED]>, Serge Knystautas writes: >No, seeking clarification to what I thought was hyberbole since you were
I already apologized for the kneejerk reaction, but I'll do it again. Sorry for accusing you of nitpicking. >claiming this code is well more (several years more) than 6 years old. Yes, the code is indeed more than 6 years old, but saying several years more does constitute hyperbole, which was not my intent. Outside of the areas of current interest, much of the code hasn't changed in that time (e.g., the smtp package). The code is showing its age and needs a significant overhaul that I hope can be done for a 2.0 release. >There are issues in the Commons Net SMTP API (notably >SMTPClient.sendMessageData() returning a Writer) that made it seem like >green code. I understand now that between other protocols being of more >interest and the nature of how the code was donated, why this is the case. 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. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
