Noel wrote: > Do you mean like the virtual user table?
Yeah Noel, like that. And before you say anything, I *know* that v. few mailet developers will want to deliver more than one kind of persistence. But I'd tend to favour us enforcing a degree of seperation between interface and implementation in all our interactions with persistent storage so that we retain, on behalf of our users, the option to develop alternative persistence for any data set, and the right of deployers/sysadmins to select the most appropriate persistence for their installation. Otherwise we'll end up with a choice for the major data sets (mail & users) but compel users to install and administer a db (or re-write someones mailets) if they want bayseian analysis of spam or virtuser or dynamic mailinglists. Virtuser should declare a repository interface, implement that in one or more ways, and deploy (currently in Avalon ways, soon to JNDI) the version chosen by configuration. I'm not "going off on one" about this, its only a niggle. Like a grain of sand to an oyster.... ;-) The simple alternative is to standardise on a single type of storage, filesystem or db and offer the other(s) as special extensions. Meaning that James would be db out-of-the-box and could be configured to use filesystem for some things only. The more elaborate alternative is to standardise on db but embed a db which would use the local filesystem. That way the change from local filesystem to network db is only as hard as editing the jdbc url (and in practice a million other things which don't really count in a sweeping generalisation ;-). Just my 2c though. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
