> -----Original Message----- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: 14 January 2003 11:20 > To: James Developers List > Subject: RE: [V3]Mailet chaining > > > surely you can simply put remote delivery in its own > processor and change the state of mail in your mailet so that > they are placed in this processor immediately after leaving > your mailet, where they will be opend by remoted delivery and > delivered or spooled for retrying. > > If this isn't enough why not? Doh! Yes it is ... > > nextly.. > > in Jamesv3 you will be able to store mail directly in the > outgoing spool where it can be picked up by remote delivery. That's good too. > > I'd also rather know what improvements you would like than > how you would like to achieve them. > My main issue at the moment seems to be the repository implementations for spool and outgoing.
* File based - slow and seems to have a massive memory overhead. Also, the current implementation writes a lot of files into a top-level directory. This can cause the OS real problems as it attempts to manage a 100000 file directory (or whatever). Qmail uses directories within the spool to make this less of a problem. Oh, and the directory cannot, as of yet, be placed on another disk for performance reasons. Yes you can do this using mount etc., but that won't help Win2k users very much. * DB based - faster, but has really serious contention issues with more than 1 thread doing delivery for example (particularly on MS SQL Server). I would like to see a JMS implementation (or similar) to allow multiple servers to deliver from one queue. A cluster if you like. We don't use user repositories, so I've less to comment on. > d. > > > > -----Original Message----- > > From: Jason Webb [mailto:[EMAIL PROTECTED]] > > Sent: 14 January 2003 10:33 > > To: 'James Developers List' > > Subject: [V3]Mailet chaining > > > > > > I can't remember if this has been discussed before, but... > > > > We would really like to able to chain mailets together in code. The > > main reason for this is so that our MLM code can directly call the > > remote delivery mailet (as I know that all mails WILL be outward > > bound). This may seem like an isolated example, so I'd be > interested > > if anyone else can come up with other uses. Remember I am > not trying > > to break the current pipeline, I'm more wanting to increase > > performance by short-circuiting mail delivery. > > > > -- Jason > > > > P.S. I believe servlets already do this (not quite sure though) > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: > <mailto:james-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
