RE: JAMES SMTP API sub-project proposal

["Peter M. Goldstein" <pe...@yahoo.com>]

Aaron,

> I have come across several projects with requirements to receive and
> process inbound mail.  Currently, the options for implementing this
(in
> java) are a JAMES mailet, or some kind of POP3/IMAP client.  However,
I
> would like to have a third option of embedding a SMTP listener into my
> application.
> 
> I propose that the JAMES SMTP handling code be split out from the
JAMES
> server and packaged as a separate API, which JAMES itself uses and
which
> can used separately from the rest of JAMES.
> 
> Requirements for this API would include:
> 
> *    The API must have no reliance on the rest of JAMES.
> *    The API must be entirely suitable for use by JAMES, without the
need
> for any 'special case' concessions being made by either side.
> *    The API must not manage it's own threads.  (The embedding
application
> should be free to control its own thread creation/destruction.)
> *    The API must not manage it's own sockets. (Again, opening of
> ServerSockets should be left to the parent application.)
> *    The API is responsible for conducting an SMTP converstion over a
pair
> of streams (one in, one out) and creating mail objects, which are
passed
> to
> a handler (implemented by the parent app).
> *    My own requirement is for inbound communication only, by does not
> preclude outbound communication if anyone else thinks that this would
be
> good.
> *    The API is responsible for compliance with the relevant RFC's
with
> respect to communications.  Where the RFC's specify mail server
behaviour,
> enough information should be passed to the parent app to allow it to
> implement the required behaviour.
> 
> I am willing to do the work required to extract this API from the
current
> JAMES codebase, with a view to its being made a JAMES sub-project.
(This
> would be on my own time, so results may not be instantaneous.)  Before
> making any start on such an endeavour, I require two things from the
JAMES
> developer community:
> 
> 1)   Acceptance that this is a desirable direction for JAMES to take.
> 2)   Some further discussion/ratification of the requirements and the
form
> that this API should take.  (e.g. public interface to the API.)
> 
> Any help would also be appreciated (of course).
> 
> If this kind of thing is aided by the promotion of JAMES to a top
level
> project, then that proposal get a +1 from me (else +0).  The separate
test
> project proposed by Harmeet also gets a +1 from me (subject to the
> availability of developers willing to do the work).  These last two
points
> count regardless of whether this particular proposal is accepted, of
> course.
> 
> 
> What say you all?

IMHO, this is a terrible idea.  The mailet API was designed to do
exactly what this proposal specifies as the primary purpose of the new
SMTP listener API (receive and process inbound mail).  There is no
compelling other reason presented for developing and exposing a brand
new API.  Developing, exposing, and supporting a new API has all sorts
of implications that I don't believe have been properly thought out.
Those include backwards compatibility, performance, robustness, etc.

Most of the behavior described here is not appropriate to an API - i.e.

> *    The API is responsible for conducting an SMTP converstion over a
pair
> of streams (one in, one out) and creating mail objects, which are
passed
> to
> a handler (implemented by the parent app). 
> *    The API is responsible for compliance with the relevant RFC's
with
> respect to communications.  Where the RFC's specify mail server
behaviour,
> enough information should be passed to the parent app to allow it to
> implement the required behaviour.

which is arguably appropriate to a provider architecture (ala JDBC,
JSSE, or JCE) but is clearly not something we should expect writers to a
an API to be responsible for. 

Moreover, there are a number of enhancements to the SMTP service that
are desired by the user community (i.e. 8BITMIME support, configurable
additional extensions a la sendmail/qmail, additional auth options) and
would be impeded if we stuck a brand new API in the middle of the SMTP
logic.

I view this as a highly undesirable direction for James to take, and
hence would -1 any changes as described here.

--Peter






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>