Mailet sub-packages

[Noel J. Bergman]

> Given all of these additions to the Mail API, (all good stuff,) perhaps
> we should think about making some sub-packages of o.a.mailet?

Actually, I think so, but perhaps not the same way that you anticipate.  I'd
like to see us ensure that the base "Mailet" package is protocol neutral.
The current package has started incrementally tying itself to SMTP and MIME.
I'd like us to take a similar approach to the servlet and servlet.http
packages.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet sub-packages

[Serge Knystautas]

Noel J. Bergman wrote:

Actually, I think so, but perhaps not the same way that you anticipate.  I'd
like to see us ensure that the base "Mailet" package is protocol neutral.


Protocol neutral?  What does that mean?  I assume we keep it focused on 
spool processing (messaging in general) and MimeMessages.  Are you 
suggesting we decouple from email addresses?  What else would you change?

The current package has started incrementally tying itself to SMTP and MIME.
I'd like us to take a similar approach to the servlet and servlet.http
packages.


servlet and servlet.http?  If this was done in the name of protocol 
neutrality, it has to rank up there as one of the worst design decision 
in the history of Java APIs.  It's one of the most widely adopted APIs 
yet NOBODY has used with another protocol aside from http...

--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Mailet sub-packages

[Noel J. Bergman]

Serge Knystautas write:
> Noel J. Bergman wrote:
> > Actually, I think so, but perhaps not the same way that you anticipate.
I'd
> > like to see us ensure that the base "Mailet" package is protocol
neutral.

> Protocol neutral?  What does that mean?  I assume we keep it focused on
> spool processing (messaging in general) and MimeMessages.  Are you
> suggesting we decouple from email addresses?  What else would you change?

Consider XMPP, which uses XML streams.  Likewise, the XMPP IETF draft spec
currently adds something to the e-mail address.  They format it as
user@host/resource.  We could contact them, and encourage them to change it
to adhere to localpart@host, and encode the resource in the localpart.

In any event, the point is simply that we have senders, recipients, message
content at the abstract, and then concrete RFC specifications of sender,
recipient, and content formats.

This is *not* a radical refactoring.  Just a basic recognition of
generalization and specialization.  I'm not married to how we do it, but I
do think that it should be accommodated.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Mailet sub-packages[spam 0.308]

[Danny Angus]

> servlet and servlet.http?  If this was done in the name of protocol 
> neutrality, it has to rank up there as one of the worst design decision 
> in the history of Java APIs.

:-D :-D




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Mailet sub-packages[spam 0.308]

[Danny Angus]

> In any event, the point is simply that we have senders, 
> recipients, message
> content at the abstract, and then concrete RFC specifications of sender,
> recipient, and content formats.
> 
> This is *not* a radical refactoring.  Just a basic recognition of
> generalization and specialization.  I'm not married to how we do it, but I
> do think that it should be accommodated.

In the normal run of things this is a resonable thing to do, but.. we currently use 
javax.mail.internet.InternetAddress and javax.mail.internet.MimeMessage as out atoms 
of person and message.
I don't think that either writing our own classes or jumping through hoops with 
wrappers will gain us much advantage for the effort involved.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: