Noel,
>>Nothing, but it is hardly a Java friendly API.
>>
>>
>
>How so? Create a mail message, add recipients, subject, content, send to
>server. Easy as pie. Even without javax.mail (a bit over engineered),
>there are ez-mail classes (or wrappers). I've been using the same simple
>MailBean for years with servlets and JSP pages.
>
>
hello("Is this a Java firendly API"); ?
SMTP, whether with helper libs or not, is not a first class Java API.
It is a plain-text using protocol that is ubiquitous and has multiple
implementations.
You missing a central point of what I propose - have a first class API
in Java, and have a number of ways of poking it (including SMTP). What
I think is inferior is constructing something around SMTP, then
forgetting easier (from the programmers point of view) ways of poking it.
>>Besides, stategic use of AltRMI or Glue will allow publishing
>>of arbiary Java interfaces. There are a dozen places in JAMES
>>code where a niche publication could occur... at no cost of
>>developing the remote API.
>>
>>
>
>I am firmly against protocol proliferation when it is unnecessary. If/when
>there is a change from SMTP/IMAP/POP/NNTP to some XML messaging protocol(s),
>there would need to be RFCs with the same kind of scope as the current
>protocols. Not ad hoc SOAP or RMI interfaces.
>
Who said change? JAMES is a mail server, it must speak RFC specified
protocols. Whet we are talking about here is direct to JAMES/maillets
API, yes?
For you information, there are loads of people using AltRMI and SOAP for
RPC. They have not felt the need to get an RFC around their API. You
folks don't have to either. Whether you talk of a new JSR or not (I am
on the committee of JSR 111). You can make a defacto standard you know.
It is not wrong to do so as you are the only mail server of consequence
in the Java world.
- Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
