In an effort to get from point A (lots of great code, not quite enough to distribute) to point B (enough to distribute), how about this... For the mail delivery/relaying component, I need a very stable queue that is/supports: 1) crash-proof... if the server dies at ANY moment, it should be able to recover and not lose or corrupt any messages. 2) query based on defined delivery/relaying logic... messages without an error get first priority, from oldest to newest in the queue. then messages with an error after X amount of time will be retried, generally depending on the kind of error. 3) meta data (message delivery process/status/logging) that is outside the actual Internet mime message 4) low/dynamic memory usage, so when I look at and maybe change info in the header or meta data (95% of the time), I don't have to load the 1 meg message with 14 attachments at each stage. I haven't seen the generic object store that can provide all this. So I'm going to write 2 things: 1) a message/delivery state object that supports what I need from points 3 and 4. 2) An SMTPRelayQueue (for lack of a better name). This will have only a few methods specific to how this queue will be used (add messages to the queue, grab the appropriate one if it's time, etc..). For now underlying implementation be damned (I will use something close to how I'd implemented the original delivery queue in James so as to support point 1 and add some code to support point 2). Once we have a generic object store that can handle this, we can rip out the code from SMTPRelayQueue that actually stores the data, replace that with the generic object store, and leave the logic in place to pull messages from the queue in the correct order. Thus we only have to change this class when we're the object store is ready. Sounds good? Serge ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: <http://java.apache.org/> Problems?: [EMAIL PROTECTED]
