----- Original Message ----- From: "Danny Angus" <[EMAIL PROTECTED]>
> My next step is a little less clear, and requires some decision making, > > I'm going to do the same thing for user repositories, so that > getMailetContext().getUserRepository(String name) > returns a UserRepository, however I don't like the incosistency between URL > specifications for MailRepositories and names for UserRepositories. +1, but not sure how we can resolve this for user repositories. > We need, IMO, to select one style and use it consistently, I favour URL's, > which allow repositories to be created dynamically by mailets without extra > config changes, but what are the other opinions? Technnically its not a big > issue but in order to ensure portability of mailets, the primary objective > of the excercise, we need to document what the string can contain. I prefer the "mount" approach because of the ability it gives us to extend the types of configurations. I also think it's better to not make the mailets aware of how/where messages are being stored... IMHO it's cleaner for the mailet to access /spam rather than know this is a DB or a file (or whatever) repository. I don't want to require changing a config file and restarting to support new mappings. Given mail repositories already support children, an admin can leave a /file mount and then just reference children below this. But more importantly I think whatever changes an admin makes should update the config file, so you can either change the config file or use the admin, and those changes are permanent. For simplicity I would put all this mounting logic into a separate config file. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
