The jsieve stuff would be need to get moved to the "core" service too.
Bye, Norman 2011/1/10 Eric Charles <e...@apache.org>: > Hi, > Tks for the information. > What about the jsieve functions? We'll we reimplement it or reuse the > existing mailet? > Tks, > Eric > > On 10/01/2011 10:54, Stefano Bagnara wrote: >> >> 2011/1/10 Eric Charles<e...@apache.org>: >>> >>> So configuration and code would the same for now, simply export them to >>> separate components (additional conf file and maven module I guess) ? >>> >>> As side effect, we should have in mind: >>> - More resources (memory / cpu / I/O) for the delivery threads and >>> queues. >>> - Additional delay for the mails to be delivered (it goes via additional >>> intermediate step) (Not very relevant, mail is store/forward, not >>> real-time) >> >> At the moment we already have a specific spool queue for the remote >> delivery (the outgoing queue). >> So every mail to be remotely delivered will be removed from the main >> spool and placed into the outgoing queue. A remote delivery thread >> will then read one mail from the queue and attempt to deliver it. >> >> IMHO this behaviour will be preserved even if remote delivery is an >> external service and this should not introduce more delay, more steps >> or more resources. >> >> In fact the current RemoteDelivery runs its own threads for processing >> and IMHO it is wrong that a mailet use similar resources like threads. >> A mailet should be as stateless as possible in order to make it easier >> to understand how it works, in order to allow distributed environments >> to distribute the load between different machines without side >> effects. >> >> This is not required by the mailet api, but I think it makes sense >> moving towards this. >> >> Either way RemoteDelivery is not a generic mailet and it won't work in >> another mailet container, so there is not much reasons to insist it >> being a mailet: or at least not a mailet that runs against the main >> spool. >> >> Stefano >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >> For additional commands, e-mail: server-dev-h...@james.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
