james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: BasicMailboxSession (aka MessageRepository)
Date Sat, 28 Oct 2006 20:39:23 GMT
Joachim Draeger wrote:
> Am Samstag, den 28.10.2006, 18:07 +0100 schrieb Danny Angus: 
>> On 10/28/06, Joachim Draeger <jdraeger@gmx.de> wrote:
>>> 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 

db / dbfile / file are already logical mount points.
I don't like it too much because we use this logical mountpoints for 
different contents (mailrepository/spoolrepository/generic db access).

I think we should simply rewrite our repository store to provide a 
single url type for every type of object available, like a virtual file 

What I expect is something like spool://some/path, message://some/path.
Then in the store we really define what specific implementation we want 
to mount in every single mount point.

I think this would be something in the middle between what we currently 
have and what you try to achieve with the "#some.path" logical name.

I also like more the use of the "#some.path" instead of 
"message://some/path" because I think this make less confusion not using 
something similar to real file system paths.

This idea already appeared here:
http://wiki.apache.org/james/JamesV3/Plans ("Message repository 
directory structure")

And maybe I already talked about this in past.

<messagestore class="VirtualStore">
   <repository mountpoint="#some" class="TorqueMessageRepository">
   <repository mountpoint="#other" class="FileMessageRepository">
   <!-- this is even more advanced because "nested" would be a file 
repository with the torque repository parent -->
   <repository mountpoint="#some.nested" class="FileMessageRepository">

or alternatively something like:

<messagestore class="VirtualStore">
   <repository mountpoint="#some" class="VirtualStore>
     <!-- default repository for this virtual store -->
     <repository class="TorqueMessageRepository">
     <repository mountpoint="nested" class="FileMessageRepository">
   <repository mountpoint="#other" class="FileMessageRepository">

Every message repository simply have to implement a method where the 
repository itself is created with a parameter that indicate the relative 
path between the mountpoint and the real path requested: as an example 
if I ask #some.nested.foo.bar the VirtualStore implementation will be 
called with #some.nested.foo.bar. From an internal lookup it will find 
#some.nested is the most specific mount point and will delegate to 
FileMessageRepository that will be called with ".foo.bar" as a detail on 
the specific repository requested.

Does this make sense?
Imho this is much more easy than what we have now, and even more 
powerful. Today if you want to move from file to db repositories you 
have to change a lot of configurations. After this new feature the 
change would need a single edit in the config file.

Now that I wrote all of this, I understand that probably this is what 
you are proposing, with the difference that you probably would have used 
something like this:

<messagestore class="VirtualStore">
   <repository mountpoint="#some" repositoryUrl="db://maildb/foo" />
   <repository mountpoint="#other" repositoryUrl="file://var/mount" />
   <repository mountpoint="#some.nested" 
repositoryUrl="file://var/nested" />

This way you would still use the current mailstore to retrieve each 
repository. It is simply one more layer (that I tried to merge to the 
current one)

Did I understand your proposal? Is my "simplified proposal" acceptable?

If all of this is ok, how would you manage the retrieval of a "child" 
repository? Adding ".child" to the logical name and retrieving it from 
the store? Or alternatively adding a getChild("child") method to the 
repository (mailboxsession) interface?


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

View raw message