> I don't see another simple solution to move forward from the current
stall.
What stall? We're certainly not going to design an API by voting first and
working second.
Meantime, we are making very fine progress on the protocol handler
revisions, which should clear the way to relatively easy support for both
socket-based and NIO-based handlers. And we should be able to easily
integrated jSPF, too.
Since we cannot use InetAddress even with dnsjava plugged in as the
provider, I plan to commit samples to show how we can easily replace those
calls with JNDI. I certainly do not expect to use that for the critical and
specific DNS work required by RemoteDelivery, but for other uses, we can do
it, e.g., in the DNSRBL code:
dnsCtx.getAttributes(host, new String[] { "A", "TXT" })
which get both A and TXT records from the DNS, which is something that
InetAddress cannot do anyway, so unless we want to mandate the dnsjava API
as part of the Mailet API, JNDI handles it quite nicely and easily.
As for RemoteDelivery, we might decide to remove the SMTP locator method
from the MailetContext, and provide a discoverable service that implements
the interface. Again, the concept being to not burden all Mailet Containers
with things that they don't need to implement.
Is there something specific you have in mind that you would like to see move
forward at this time?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
