> > 2- RemoteDelivery: reuse/sort connections to the same hosts (mass > delivery) > > +1 ... HOWEVER, that must be tunable. Perhaps we'll want subclasses for the > actual delivery engine. > > > 3- RemoteDelivery: better error handling based on specific ESMTP / DSN > > reply codes. > > +1. Mind you, JavaMail isn't the most helpful thing on the planet in this > regard. I wrote most of the error detection code to pick up what we were > getting back, and it is admittedly a hack.
What we need to do here is write our own JavaMail SMTP Transport. And attach listeners to handle transport events. Use listeners to handle message events too. > Unrelated for the moment, but does JMS support a JDBC transport? I would > like to see us able to store messages in a database on a cluster, and not > have to actually send the messages around. Depends what implementation you use. JMS is a messgeing system specification, you don't want a shared queue, just multiple publish/subscribers to distribute the work, If you want the JMS messages not to contain the email message content you should publish a key that allows a subscriber to access the message. If you then use a high availability (HA) database for the email messages you should get what you want (small payloads/ lazy loading in James) without specifying how the database manages to achieve its high availability. d. > Also, I'd like to see us make use of Derby out of the box. That way, we can > count on JDBC support in all cases. People can then switch to MySQL, > Oracle, DB2, or what-have-you, but we can always count on JDBC for > functionality. Derby recently added support for network clients, so we can > eventually use that, too. Thats a no-brainer, it really only needs sqlresources and config.xml updating. Of course to go the whole hog it would be nice to have stored procs. and functions to tailor the efficiency of derby for James' use, which would really require us to deploy derby in standalone, multi-user mode to overcome the limitations imposed by embedding it. > > Jdk1.4, POJO, Mailet API refactoring and this kind of changes will > > instead require a 3.x branch. I'd be much more comfortable if we had a single plan and minimal branching. part of the cause of the inactivity we've had is the block we imposed by having a significant branch. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
