Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Danny Angus wrote: ... JavaMail is explicitly and in its detail a mail client API, it lacks support in may areas for the kind of server functionality James provides and it is not always easy, and often impossible, to force James to use JavaMail interfaces and classes for many of the tasks of a server. ... Reflecting upon what Danny wrote, I wonder if Sun ever considered the possibility of dividing the existing functionality in the JavaMail API. It would be great for us if this existing functionality were divided into a basic set, tools useful to both servers and clients, and an extended set, just for clients. Then we developers of servers could employ the basic set without having to disentangle ourselves from the features intended for clients. JavaMail includes a lot of important, basic work, promising to ease the burdens of other developers. Because of this, we developers of servers find ourselves sucked in, trying to use the good stuff that is inside JavaMail for our purposes. But JavaMail would be much more valuable to us if the basic tools were exposed free of the stipulations which have been added for clients. Rich Hammer Hillsborough, N.C. mailscreen.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Rch, Reflecting upon what Danny wrote, I wonder if Sun ever considered the possibility of dividing the existing functionality in the JavaMail API. It would be great for us if this existing functionality were divided into a basic set, tools useful to both servers and clients, and an extended set, just for clients. Then we developers of servers could employ the basic set without having to disentangle ourselves from the features intended for clients. Judging by the minimal experience I have of communicating with them they don't give a damn about us. When asked about the possibility of modifying MimeMessage to make it applicable to the general case, and allow it to be specialised for each specialisation the answer was a resounding NO, justified by the assertion that JavaMail Is a client API. In spite of it flying in the face of good OOD and being little more than a nasty hack which lets them do a tiny bit less work but compells James to use up clock cycles for no good reason. Yuk. :-) d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP implementation questions
Hi Danny, On Nov 10, 2003, Danny Angus wrote: Zoe, (Beware, long answer!) Thanks for the explanations :) Ist point.. James IMAP component is very much alpha status *still* . Oh, well... that would make only three incomplete IMAP implementations I know of: James, JimapD and Foedus. Do I see a trend here ;) [snip rational] So.. What is the answer for ZOE... Well my impression of James is that I think that it would be foolhardy to take James' alpha IMAP and try to rewrite it with no reference to James, Avalon or Mailet and I think it would be exceedingly tortuous (but not necessarily impossible) to implement an IMAP server using JavaMail. I'm going to find out very soon as a solution stumbled upon me: a lightweight, IMAP SDK build in terms of the JavaMail API. With such a toolkit, one only needs to provide its own implementation of a javax.mail.Store to the SDK. The SDK handles all the IMAP protocol minutia and interact with the underlying data through the Store, Folder and Message API. All this in a small package and no other dependencies than JavaMail :) It might be worth looking at Avalon Phoenix or Merlin and see whether you could implement (or integrate) a container within ZOE to allow you to run IMAP. Well... this is what I would like to avoid in the first place. Thanks for the walkthrough in any case :) Hopefully I will not need to highjack James IMAP implementation to turn it into something it was not mean to be. That said... I still think there would be some values in repackaging James different protocol stacks to make them more accessible to third parties. Something to think about perhaps. Cheers, Z. -- http://zoe.nu/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Thank you, Bill. Even though I raised this point, I doubt that I'm the best person from the James Developers list to respond to your saying, If you think some great advantage could be had by splitting the APIs in this way, tell me more. I guess that Danny, Noel, Serge, or others, might be able to quickly throw together a list of ways that life could be made easier for us if more of the basic functionality inside JavaMail were made accessible without the requirements for clients. Assuming that I have actually represented the needs of James developers, I hope that others from this list might respond. I don't know if a list of our needs might rise to the level of a great advantage from Sun's viewpoint. You are probably right that there are many fewer server-side projects than client-side projects. Rich Hammer Bill Shannon wrote: Richard O. Hammer wrote: Danny Angus wrote: ... JavaMail is explicitly and in its detail a mail client API, it lacks support in may areas for the kind of server functionality James provides and it is not always easy, and often impossible, to force James to use JavaMail interfaces and classes for many of the tasks of a server. ... Reflecting upon what Danny wrote, I wonder if Sun ever considered the possibility of dividing the existing functionality in the JavaMail API. It would be great for us if this existing functionality were divided into a basic set, tools useful to both servers and clients, and an extended set, just for clients. Then we developers of servers could employ the basic set without having to disentangle ourselves from the features intended for clients. JavaMail includes a lot of important, basic work, promising to ease the burdens of other developers. Because of this, we developers of servers find ourselves sucked in, trying to use the good stuff that is inside JavaMail for our purposes. But JavaMail would be much more valuable to us if the basic tools were exposed free of the stipulations which have been added for clients. We did some of this. We separated the pieces of JavaMail into the core API piece and the protocol provider pieces. That allows you to pick just the pieces you need. But we haven't considered carving the core API piece into multiple pieces. And we wouldn't consider doing anything of that sort that would break compatibility with the existing API. Requiring servers to carry around the additional client parts of the core API doesn't seem like a great burden. I'd be more concerned about adding significant new server support that clients were required to carry around. If you think some great advantage could be had by splitting the APIs in this way, tell me more. I think the more interesting question is how much can we morph the APIs into something that's more useful for servers without compromising ease of use for clients? I expect there to be many thousands of applications using JavaMail for client mail access. I only expect tens (at most) of applications using JavaMail to implement mail server functions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with outgoing email
Chandru wrote: Hi, Took me a bit of time to figure out that I need to point James to the apropriate dns server (default is localhost). The nameservers are set correctly (I am using yahoo's namesservers currently). The emails seem to be going out from James: 10/11/03 20:21:50 INFO James.Mailet: RemoteDelivery: Attempting delivery of Mail1068513709624-10-to-yahoo.com to host mx1.mail.yahoo.com. to addresses [EMAIL PROTECTED] 10/11/03 20:21:51 INFO James.Mailet: RemoteDelivery: Mail (Mail1068513709624-10-to-yahoo.com) sent successfully to mx1.mail.yahoo.com. Your server is successfully delivering it to yahoo's mail server, so it seems like it's a Yahoo! issue if it doesn't arrive in your mailbox. I could only guess that they have some spam blocking in place. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
