On Dec 1, 2007 11:28 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: > > > Noel J. Bergman wrote: > > > what are the real-world use cases for using JMS as that method, and > > > how would it improve on JavaMail or a simple wrapper around it? > > > by not having to run SMTP > > Non-answer, unless the SMTP protocol is the problem, e.g., if you have a use > case where one might have JMS in an environment, and cannot (e.g., firewall) > use SMTP. The SMTP protocol need not be exposed to the client code, and it > is simpler to configure the client side of an SMTP transport than for JMS.
i don't advocate targeting JMS as a correct remote delivery alternative to SMTP the use cases which would be effectively targetted by JMS are analogous to local delivery (whether via FetchPOP or by a local MTA) so, the entire answer is: by not having to run SMTP > > JEE developers are familiar with JMS and unfamilar with mail. > > I don't agree, plus you are talking about JEE developers who want to inject > a MAIL message into a MAIL server. JEE developers who aren't confortable running SMTP are probably not confortable with mail > > SMTP has a well deserved reputation for being hard to administer. > > That requires explanation. If you mean programs like sendmail, qmail, > postfix, et al, fine. But we're talking about client code, not server code. asking users to run the SMTP server just to allow mail to be delivered into the JAMES processing spool is a little unreasonable > > > - create reply queue > > > - create consumer > > > - send message > > > - receive reply for status > > this is over-engineering for typical fire-and-forget use cases we're > > talking about > > I don't agree. And if we support JMS on the server side, we should code to > support a reply-to destination. definitely not! i'm not targeting a correct remote delivery protocol over JMS but simple fire-and-forget. (if users want a full, correct protocol, they should use JavaMail-SMTP.) let the broker handle acknowledgements, persistence and so on. > > > The JAMES pipeline is based on SMTP routing information, which comes > > > from the envelope. And, no, JavaMail's MimeMessage is not sufficient, > > > unless you want to implement the assumptions forced upon FetchMail. > > > You want an explicit envelope for the message, which we would have to > > > invent and support. > > > yes, just like FetchMail. JAMES is already more than a SMTP server. > > it's not unreasonable for users to ask (as they do) why if JAMES > > supports FetchMail, they can't inject mail into the spool. > > Again, really bad idea. Fetchmail has to recreate the SMTP envelope from > what it finds in the message, and is not able to be accurate all the time. > If you want to do something with JMS, let's do it right. doing it right depends on the use case using JMS as a replacement for SMTP would be difficult. i'd be happy for someone to take this on but it's not my itch. there are more limited but much-requested use cases that can be addressed easily the mailet API requires envelope information. so, inserting mail into the pipeline which does not arrive via SMTP requires envelope creation. JAMES already supports this. > > unless a mail is received via SMTP the envelope has to be derived from > > the headers in any case. JAMES already support this. the question you > > need to be asking yourself is if this new function is wrong then what > > needs to be fixed in the rest of JAMES? > > It is not a matter of fixing Fetchmail. Fetchmail does the best it can to > deal with an information mismatch. There is no reason to provide a new, > ad-hoc, JMS injection point with a designed-in and unnecessary mismatch. As > I said: > > > > If anything, I'd package it as a builder for use on the client side, > > > not the server side. The server side should expect a payload > > > containing a proper envelope and message. > > So we provide a factory for creating a JMS message from any of several > origins, e.g., plain text + envelope, MimeMessage + envelope, MimeMessage > with derived envelope. this addresses your use case, not mine for mine, the SoC's wrong in the client side solution. JAMES should do the mail. forcing users to adopt a proper remote delivery protocol is unnecessary, heavyweight and inflexible. i'm happy for someone to address this but it's not my itch. take a look at the code all the lightweight framework does is ensure that a couple of extensible components are called at the right time in the right place. a message arrives. it's turned into a mail suitable for processing by JAMES (including required envelope information) by the builder. it's then processed by the consumer. neatly and quickly addresses the narrow use case. an extension point on entry is more flexible and powerful. the user should understand the message format they expect and the characteristics of the mail they want to be pushed into JAMES. all they need to do is implement MessageBuilder: simple, easy, quick. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
