Am Samstag, den 28.10.2006, 18:07 +0100 schrieb Danny Angus: > On 10/28/06, Joachim Draeger <[EMAIL PROTECTED]> wrote: > > > Okay there is one point that is a bit more difficult: > > ToRepository Mailet, which accepts a url. > > It is used for mail that is not delivered to a user like spam or mail > > that can't be delivered. > > I guess the ability to put this repositories where ever one wants is > > quite popular. > > Yes very. > I think that your idea for easy access is OK but it shouldn't replace > URL access. > URL access is vital for people who want James to create distinct > repositories for filtered or copied mail (e.g. archiving). filtering > by user is only one (important) way in which people using james want > to sort mail.
Is the flexibility of URL access lost when there is a mapping in between? A logical name can be constructed the same way a URL can. Okay there might be a use case where the position on the filesystem/db has to be completely free determined from an external source / at run time. We could still provide the ability to use a URL. Maybe with limited features. > > Maybe we could use a logical #system name space here like #system.spam > > or #system.address-error. > > For example this could be mapped like: #system.* -> file:/var/mail/* > > Yuk, whats wrong with file:/var/mail if thats really where you want to put > it?? Why does linux mount different filesystems into one logical root filesystem? (The idea was #system.spam becomes translated to file:/var/mail/spam) Benefits of logical names: * dealing with hierarchy, Quota and ACLs * they could be accessed in a programmatic way by IMAP :-) * redundancy - if you have many ToRepository that all resist under file:/var/mail and you switch to db you have to modify all the Urls * safety - custom code can modify only the logical name > Plus the db URL will actually create the tables for you if it needs > to, how great is *that*? The table could still be created when a logical name is mapped to a URL. > James has always been intended to be highly flexible, you can > configure it in infinite different ways. I will always be nervous of > replacing open-ended flexibility with functionality which only applies > to specific use-cases. What you are proposing assumes that people will > always want to use James the way you think they do now. This isn't > true. No, I'm not proposing replacing flexibility. Just hiding complexity. Well, I guess the problem is that I personally don't even have much experience how it is used now. So I need your help here! Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
