How about some kind of simple standardized interface to file repositories (perhaps this already exists) and a factory to select the appropriate implementation from file type information in the configuration file.
If you combine this with a facility in the configuration file to specify the location and type of a repository and the location and type of an old repository that is being replaced then... you could have some simple code that would automatically check the old repository and, upon finding content, read the content using the old classes and write it to with the new. This removes the need for any automatic repository type checking code, allows users to locate old repositories wherever they want, maintains the type data in the configuration file - which users are likely to try to maintain between installations, and allows conversion to happen as part of the startup process avoiding any slowdown in day-to-day processing. Stuart. On Thursday, December 6, 2001, at 03:22 pm, Serge Knystautas wrote: > I would like to have these file repositories be as "smart" as possible so > when they see content of a particular type, they can move it to the new > version appropriately. I was figuring the would be able to handle the > pair > files that are now, so you could seamlessly upgrade your client. This > would > take some planning since you need to determine how you detect that a file > is > of a particular format, how you split apart/migrate, and how you go from > a > MimeMessage data to Mail data. Yeah, probably a proposal would be best > for > this much of a change. > > ----- Original Message ----- > From: "Danny Angus" <[EMAIL PROTECTED]> >> >>> -----Original Message----- >>> From: Serge Knystautas [mailto:[EMAIL PROTECTED]] >>> Sent: Thursday, December 06, 2001 2:04 PM >>> To: James Developers List >>> Subject: Re: Reliable DB connections >>> >>> >>> Yes I agree. Here's what I would like to do. >>> >>> a) make an mbox file mail repository for pop3 accounts (and >>> whatever else), >>> b) a file based spool repository basically combine the stream & >>> object store >>> repositories into a single file. While the pair file is nice, it's > proven >>> to be extra work, and it's not really that difficult to combine the data >>> into a single file (and I don't see a big benefit out of separate > files). >> >> I'd go for this if .. a plain text RFC822 message placed in the spool > would >> be picked up and processed. >> or if mbox files found in the spool dir could have their contents > extracted >> and processed. >> (then local delivery could be into the JAMES spool) >> >> >> Perhaps we need two spools, a pre-spool directory from which files are >> inserted into the real spool as if they'd been recieved by SMTP, and a > real >> spool where they are processed from. >> >> I suppose that'd need to be a proposal first? >> d. Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos) Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF ------------------------------------------------------------------------- Stuart Roebuck [EMAIL PROTECTED] Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS <http://www.adolos.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
