Robert Burrell Donkin ha scritto: > On Nov 5, 2007 11:21 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> Robert Burrell Donkin ha scritto: >>> [...] >>> the MimeMessage API is unsuitable for independent implementations. if >>> it were a lighter interface then it might have been possible to expose >>> only those quantities of data which were requested. the design of the >>> API means that this isn't realistic. >> I don't agree. It is more difficult than simply implementing interfaces, >> but it is not so unrealistic. > > it's unrealistic to specify a MailboxAPI that's so difficult that no > one else will attempt a performant implementation. IMAP is a difficult > protocol. insisting that data is accessed through MimeMessage just > increases the work required. JAMES IMAP has seen many developers > start, try and then fail. we need to keep things as simple as > possible. > > the other problem is that the IMAP protocol cannot be performantly > implemented by use of MimeMessage alone - additional requirements > beyond the standard javamail specification would be necessary. in > particular, a number of the poorly defined optional methods *must* > return accurate data.
I still don't see blockers in the MimeMessage itself, but I'm fine with your choices: you are the one working on this, you can decide similar things, IMHO. Making things to work correctly is an high priority: if you can do this by removing Javamail then it is a good idea. We don't need to find problems in javamail to decide to remove it. >> If you look at our MimeMessageWrapper you can see we can override almost >> anything from the original MimeMessage by simply extending it. In fact >> in MimeMessageWrapper we can lazily load both headers and the body and >> we could even cache the structure of the message or use mime4j to do the >> real parsing. > > of course it is possible to create an implementation that just > overrides every method. the problem is creating an implementation that > complies with all the designed contracts yet at the same time > satisfies all the IMAP requirements. I think it is feasible, but again, the first goal is getting things done. So I say let's keep an interface similar to the public methods used by Javamail so if someone will have the time and skill to make it work also keeping javamail compatibility we have already some step in the right direction. Of course this is just a suggestion and is not so important: refactoring is easy in java when the code has a good architecture. >> Maybe there is some limitation in the objects we can store to >> MimeMessage that I can't think about right now, but they are not (IMHO) >> the above. Just look at MimeMessage source code and you will find that >> it is not an heavyweight object as you describe it. > > i describe it as heavyweight since: > > 1. it's not an interface and uses inheritance rather than delegation > 2. it does too many jobs bad > 3. it has too many methods Ok. This explain the misunderstanding: I thought at "heavyweight" as something slow/big in term of CPU/memory in the JVM. >> Can we take a concrete case where MimeMessage is bloated and we can't >> live with it? I don't like javamail too much, but I also don't like FUD >> based on a common criticism made to javamail. >> >> Here is a list of methods from MimeMessage. >> [a lot of methods] > > thanks for demonstrating my point! > > an implementor is forced to override a lot of methods IMHO most of them are very useful if you want to give a simple api to mailet writers. It is ok to have a method to set the Sender, other to add/remove recipients, to change the subject, to change the date and so on. Otherwise the "user" will have to know some part of rfc2822 to correctly create/alter a message. I often criticized javamail, but apart the missing interface I don't see many problems in MimeMessage itself. We probably would have done something similar if we didn't have MimeMessage. rfc2822 is a big specification, and splitting it in dozen classes would have not simplified the API. To be clear if we sooner or later will remove the dependency on javamail at all I'm for having a "Message" with a lot of helper methods to alter each header according to rfc2822 without having to deal directly with full headerlines or the full stream at all. Let's remember that Mailet writer are not rfc2822 experts. Of course we didn't define that Mailet writer will have to know MailboxAPI, so as long as we are talking of a Message interface limited to the MailboxAPI I can agree on something smaller. >> In the end they make sense to me, most of them are helpers to simplify >> some header access. In MimeMessageWrapper you can already see that I >> added some check to lazy load headers/body depending on the called >> methods. I also remember I disabled lazy loading of the headers because >> of a bug, but if this is the only performance issue we can try to fix i > > there are *many* performance issues I hope you understand I would have preferred a single real use case than a generic "*many*" reference ;-) BTW this discussion does not worth anymore, as you are the one that will do the work, and I have no time to create a better proposal. At this time I'm fine with what you propose, even if I don't share your concern and the reasons behind it. >> I guess the key part you refer to is the content handling part. >> >> I don't see "weird" methods but the DataHandler stuff from the >> activation framework (JAF). >> >> The DataHandler (as always in javamail) is not an interface but a class >> and unlike MimeMessage it expose much less to subclasses (it contains >> many private fields). >> >> If you think the DataHandler is the key weakness of MimeMessage I can >> investigate further to understand how we can optimize things, but before >> working on this I'd like to know if this is the case or if the simple >> use of Enumeration and primitive arrays is already something that make >> you discard this technology (or if it is something else). > > i agree that use of JAF is a key mistake but it's not the only one > > the API is (in places) poorly defined or optional. some of these > poorly defined, optional APIs are crucial for IMAP > > - robert We already dealt with this issue in MimeMessageWrapper, and I think no one can understand your frustration better than me ;-) . I just wanted to make sure that you knew JAMES Server already have its own implementation of MimeMessage written to overcome most of the limitations we found. A missing thing in the current implementation was to replace the parser with a mime4j parser, but noone found the time to do this in past. I think parsing (and the JAF stuff) is the only thing we still delegate to javamail. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
