james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger <jdrae...@gmx.de>
Subject Re: BasicMailboxSession (aka MessageRepository)
Date Sat, 28 Oct 2006 18:09:51 GMT
Am Samstag, den 28.10.2006, 18:07 +0100 schrieb Danny Angus: 
> On 10/28/06, Joachim Draeger <jdraeger@gmx.de> 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
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
We could still provide the ability to use a URL. Maybe with limited

> > 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

(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

> 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!


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message