Moderator (MDR): MDR-Andrea
Guest Speaker (SPK): SPK-Bill Shannon, SPK-John Mani, and SPK-Chris Cotton
MDR-Andrea: Hello and welcome to Java Live. Today we have Bill Shannon, John Mani, and Chris Cotton with us from the JavaMail engineering team. Perhaps you've had a chance to take a look at the spec on the JDC web site and have some questions, go ahead and start sending them in.
garyfreeman: Hi, my question is: Why aren't the classes in the mail package serializable (i.e. Message or Multipart)? I believe having support for serialization would probably make it easier to implement methods like, saveChanges(), putByteStream(), etc. Are there any plans to add this support later?
SPK-Bill Shannon: We largely designed the JavaMail APIs to work with existing messaging
systems, so we need to control the format of the data to be compatible with those systems. Serialization wouldn't allow us to do that. There may be other motivations for making these objects serialializable, which we'll consider for future versions.
mtownsen: Is my understanding correct that you can essentially create a JavaTM POP3 email client program using this API?
SPK-John Mani: Correct. Of course this will require that a POP3 service provider be available and installed. We don't have plans yet for providing one ourselves. Other vendors might. The reference implementation that we provide will contain an IMAP4 service provider and an SMTP transport provider. We plan to release early access versions of the implementations later this year. Watch for annnouncements about this shortly.
Hi, mtownsen. To your question on POP3, it is not typically possible to connect to any random POP3 server from an applet using JDKTM 1.1. However, if your browser allows you to relax access permissions so that a connection can be made to another machine, this will work. Also, in JDK 1.2, additional protection/security mechanisms exist which will allow you to do so. Wait for JDK 1.2 :)
garyfreeman: The way the specs currently stand, there is no message delievery function in the framework. I am currently working on an email-like system, and I'm having trouble properly designing that piece. Are there any plans to address that functionality? Specifically, I would like to know how to go about extracting data from an input stream, putting them in messages, and storing them in a folder.
SPK-Bill Shannon: You're right, there is no message delivery function. That piece is typically handled by existing pieces of a messaging system, such as the SMTP server. You could, of course, write a pure Java SMTP server, a pure Java IMAP server, or whatever; but those elements aren't currently a part of our framework. Those servers might want to make use of some of the JavaMail classes, such as the support for Internet/MIME messages. For instance, the javax.mail.internet.MimeMessage class can be used to construct a MimeMessage object from an InputStream.
garyfreeman: I have a couple of API-specific questions: First, why doesn't the message class have a setFolder() method to go along with getFolder() method, which would be used to assign a message to a particular folder? Second, why isn't the reverse operation of putByteStream() available which could be used to reconstruct a message (i.e. getByteStream())?
SPK-Bill Shannon: Message.getFolder() indicates which folder a message is stored in. To store a message in a different folder, you need to use Folder.appendMessages or Folder.copyMessages. I'm not sure what you're asking about in regards to getByteStream. You can construct a MimeMessage from a byte stream.
steelman: Will JavaMail be part of the JDK 1.2 base packages?
SPK-Bill Shannon: No, the implementation will be released as a Java Standard Extension that will run on both JDK 1.1 and JDK 1.2.
garyfreeman: Another API question: getContent() uses the DataHandler internally to obtain the native form. Is this also true for setContent(), or is another mechanism used?
SPK-Chris Cotton: I am assuming you are talking about the Message.getContent() and Message.setContent()
It does use DataHandler to get the content in its native Java object form. It is also true for setContent().
SPK-John Mani: Disconnected support is a very important piece, and we are working on this. We plan to add a set of APIs to support this in the next version of the APIs, so that all the complexities (caching, disconnection, resync, etc.) associated with disconnected usage are hidden from the client.
For this release, we are thinking about adding IMAP like UID/UIDValidity support so that clients can get the bare necessities to implement disconnected usage themselves. We are actually soliciting input on whether the latter is a good (interim) option.
steelman: Although not yet supported, can you tell me about "disconnected operation?"
SPK-Bill Shannon: We haven't integrated any directory services or address book support into the JavaMail APIs. JNDI can certainly be used to access directory services. We're looking at various options for personal address books. One possibility is to store that information in (e.g.) an LDAP server using JNDI. Another possibility would be to use the proposed ACAP protocol. We don't yet understand how to handle all of this in a protocol-independent manner. Certainly an application using JavaMail can do this however it wants and construct Address or InternetAddress objects.
steelman: A mail message may have several attachments. Does JavaMail support the notion of the user controlling the downloading of each of those attachments independently of the mail message (after the message, of course) and independently of the other attachments associated with same mail message?
SPK-Chris Cotton: When you get the attachments you will get a BodyPart. "When" the data for this attachment is downloaded, it is implementation-dependent. But in the case of IMAP, the data will not be downloaded until you get the content of the BodyPart (by using getContent(), or getting the DataHandler and getting the inputstream, or having it write it out as a stream). Basically, the data should not be downloaded unless the content is accessed. But in the case of POP3, the data would already be downloaded--since there is no way to download a partial message.
JonathanK: In the JavaMail API preview release, there were reference calls to importing javax.mail.*, etc. Do these files exist anywhere?
SPK-John Mani: javax.mail is the package that implements the abstract mail layer. javax.mail.internet provides the `Internet' implementation of the abstract layer. We are currently working on these implementations and will be releasing early access versions later this month/early next month. Watch for announcements regarding this shortly.
SPK-John Mani: Hi, all. We'd like to know about the quality of the specification document. Are there any areas or chapters that need more work, any sections that are not clear and need improvement?
wwake: Is there a facility for searching the folders? I'm particularly interested in being able to search across all folders at once. (I'm only halfway through the spec, so forgive me if it's addressed there.)
SPK-Bill Shannon: Not currently. Since our focus is currently on IMAP, and IMAP doesn't yet support such an operation, we haven't been motivated to add it yet. You could create multiple threads in the client and have them each search a folder or set of folders, but that wouldn't allow message stores that can internally optimize this to do so.
steelman: Can a mail message exist in more than one folder, or multiply in a single folder?
SPK-John Mani: A mail message can be copied over to another folder (within the same Store or another Store). So a copy of the message can exist in more than one folder. A mail message may also be copied into the same folder, so you can have the possibility of duplicates as well. Note that all this depends on the underlying implementation, and the restrictions it may impose on such operations.
rsl: I've heard that the IETF has recently set up a committee to look at Open-PGP (in the future maybe S/MIME), which has been proposed to become a standard for sending secure mail messages over the Internet . Will JavaMail support these standards? If it will, what specific support will there be in the first release/future releases?
SPK-Chris Cotton: In the JavaMail API, not in the first release, we will be adding general security APIs. There is a discussion of the plan for these Security APIs in the JavaMail Spec (Appendix D—Message Security). We plan on releasing the Security APIs for free, but it has not be decided if the implementation will be released, or even if it can be released because of the licensing we have to pay for the S/MIME libraries. The JavaMail Security APIs should be able to support any of the standards. I am currently the contact for Security in the JavaMail group.
SPK-John Mani: Hi, all. We would like to know how many of you are interested in using these APIs to write mail-enabled apps, and how many are interested in writing service providers that implement specific protocols underneath these APIs.
JonathanK: Where can we get those Security APIs?
SPK-Chris Cotton: The Security APIs are not available yet, but will be available for review early next year. (Look for them in the same location as the JavaMail API spec—JDC Early Access.)
garyfreeman: I am trying to get a feel of how some of the Message class methods are supposed to work. For instance, if you do Message.saveChanges(), does it save the attributes, and contents in one single file, or in separate files, and does it use the fileName attribute for the name of the file? What happens in the case of a mulipart message?
SPK-Bill Shannon: The behavior of saveChanges depends on the "service provider," whether it's IMAP, POP3, or whatever. Different service providers will handle this differently. The spec attempts to describe the constraints on the service providers, and what users of the API can expect. If you're dealing with a message retrieved from an IMAP folder, you can't change the message, so saveChanges is an error. If you're constructing a new MimeMessage to be sent, saveChanges will cause it to update all the header fields, which depends on the content of the message—such as Content-Transfer-Encoding. We have a prototype implementation that works with the UNIX mbox file format. Message.saveChanges causes the header fields to be updated, and causes the modified message to be written back to the file when the folder is closed.
rsl: I have had a quick look at the appendix about Message Security. It seems to focus on S/MIME. From what I have understood so far, the licensing topics aren't of concern if you decided to go in the Open-PGP direction. Have you looked at Open-PGP yet? Until today, Open-PGP seems to have reached further than S/MIME.
SPK-Chris Cotton: We have looked at Open-PGP and are considering it as one of our options. We are also participating in the IETF with regards to S/MIME and PGP.
JonathanK: I am working on a project in the medical field, and am trying to complete a mail API specification for usage in the program. One part of the program is having attatched viewable files with the mail containing lab reports, etc. Is there a way to incorporate page breaks on the data when printing the document?
SPK-John Mani: There is no direct printing support built into the mail APIs. The idea is that you use the Java Activation framework to get an appropriate "Print" bean, and that bean might provide you options to do this. Of course, you can always use getInputStream() to obtain a BodyPart's content, and then write a filter that processes that input stream before dumping it out to the printer stream.
MDR-Andrea: Thanks to everyone for joining the discussion today, especially our JavaMail team guests—Bill, John, and Chris. If you have feedback for the JavaMail team, send mail to javamail@sun.com. Also, be sure to check out the spec (on the JDC site), if you haven't already done so. Thanks again, and see you next week.
