Jason, I missed it if the in-memory form is only necessary in memory for POP3 operations. So you are saying that for archiving operations, it is scalable as long as no one ever opens it through James? Since I perceive that to be the primary use for mbox, that might be OK.
If you don't think that dotlocking would be too much effort, it might be worthwhile in terms of making the code more general. FWIW, http://bluezoo.org/knife/ has a link to an mbox JavaMail provider, which implements dotlocking, if you want to see how Chris did mbox and maildir. Your call as to what you think best for the moment. :-) Eventually, I think that we want James to be configurable to be compatible with the widest range of mail tools. --- Noel -----Original Message----- From: Jason Webb [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 3:37 To: James Developers List Subject: RE: [PATCH] mbox mail repository On Fri, 2003-08-08 at 04:59, Noel J. Bergman wrote: > Jason, > > Is there something you can do to address the scalability? I didn't realize > until I read through it that you keep the entire mbox in core during > operation. That would prevent it from being used to archive mailing lists, > since those files could grow quite large. > Correct, and as you pointed out less than ideal. However, the mbox is only read into memory when someone wants to read it via James (POP3). If you just want it to store messages then they just get appended to the current mbox file (on disk). I also have a plan B. I could treat the mbox file like an ISAM file and do all the operations on disk. The only thing I'd have to store in memory would be the keys. Then I would have to write dot-locking as the risk of a collision with another mbox updater would be that much greater. This would be slower, but it would work. Opinions? > --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
