james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Mailet API v2
Date Mon, 03 Jun 2002 20:09:51 GMT

>>You missing a central point of what I propose - have a first class API
>Define a message delivery API, do it in SOAP, make it language neutral, and
>submit it as an RFC.  THEN you'll have something.  A SOAP interface to
>replace SMTP and other message delivery protocols makes sense, but the model
>should not be tightly tied to any language or implementation.  My objection
>is to an ad hoc protocol entwined with a particular architecture, rather
>than abstract concepts of message delivery.
SOAP is not first class. I am not proposing it.  I am proposing a Java API.

>>constructing something around SMTP, then forgetting easier
>>(from the programmers point of view) ways of poking it.
>I've never thought of SMTP as a difficult protocol.  But then again, I've
>been known to send e-mail via telnet.  SMTP can have a perfectly simple
>object interface: set content, set recipients, send the message.  It is not
>an interactive interface, but that's not its purpose.
It is more difficult than Java.  If it is great why do we not have a 
Hashmap interoperated with via SMTP (for example).

>>What we are talking about here is direct to JAMES/maillets API, yes?
>That became clear later, and I maintain that THAT is a bad idea.  Having to
>take into account that any given matcher or mailet could be remote (and
>perforce unreliable) is going to really complicate spool processing, and I
>honestly see no point to it when I can send the message via SMTP or LMTP
>from one mail server to another, just as we do with almost every other mail
>server on the planet.
All of them, any of them, some of them.... Some front end API that 
firewalled them all.  It is not such a bad idea.

>>For you information, there are loads of people using AltRMI and SOAP for
>I am well aware of SOAP and other RMI mechanisms (I'm one of those sick
>people who browses http://www.xmethods.net to see what's new).  As I said,
>I'm in favor of a SOAP interface that is based upon the problem domain, not
>the solution domain.
I am not propsing a SOAP or AltRMI or SMTP API.  I am proposing a Java 
one.  Then and only then thing of secondary adapters that present it to 
the outside world.  Add in additional concepts like TLS, AAA and you're 
got multiple faces to the same JAMES concept - a specially designed API.

- Paul

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message