james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject Re: BasicMailboxSession (aka MessageRepository)
Date Sun, 29 Oct 2006 15:09:35 GMT
Stefano Bagnara schrieb:
> 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 system.
> 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.
We are probably thinking of something very similar. :-)
> 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.
the #mail.joe.INBOX or #users.joe.INBOX is a commonly used 
quasi-standard for IMAP. It's called namespaces there. Theoretical 
naming schemes could be freely defined when using IMAP, but I'm not sure 
whether a URL like message://some/path  will work. (A slash as a 
hierarchy delimiter is okay)
Anyway IMO we should follow a commonly used IMAP standard here. People 
with IMAP experience (probably many mail-server administrators) will 
feel at once familiar.
We should avoid translating a custom James virtual naming scheme for 
IMAP access..
> <messagestore class="VirtualStore">
>   <repository mountpoint="#some" class="TorqueMessageRepository">
>     <tablename>foo</tablename>
>   </repository>
>   <repository mountpoint="#other" class="FileMessageRepository">
>     <filepath>%{app.root}/var/mount</filepath>
>   </repository>
>   <!-- this is even more advanced because "nested" would be a file 
> repository with the torque repository parent -->
>   <repository mountpoint="#some.nested" class="FileMessageRepository">
>     <filepath>%{app.root}/var/nested</filepath>
>   </repository>
> </messagestore>
> or alternatively something like:
> <messagestore class="VirtualStore">
>   <repository mountpoint="#some" class="VirtualStore>
>     <!-- default repository for this virtual store -->
>     <repository class="TorqueMessageRepository">
>       <tablename>foo</tablename>
>     </repository>
>     <repository mountpoint="nested" class="FileMessageRepository">
>       <filepath>%{app.root}/var/nested</filepath>
>     </repository>
>   </repository>
>   <repository mountpoint="#other" class="FileMessageRepository">
>     <filepath>%{app.root}/var/mount</filepath>
>   </repository>
> </messagestore>
I would prefer the first example. For MailboxManager I've decided to use 
a "flat hierarchy". Until it is really needed mailbox names (that 
consist of a logical path) are just mailbox names and treated hierarchy 
Most of the times no hierarchy is needed and would be just overhead.
> 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?
This is exactly what I have in mind.

> 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" />
> </messagestore>
> 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)
This would be my first approach because I'm going to try to be backward 
compatible.This way we wouldn't need to change current mailstore.

> Did I understand your proposal? Is my "simplified proposal" acceptable?
Yes I think we agree. Your merged configuration proposal will be perfect 
in a longer term.
Maybe we could even avoid the intermediate step #some -> url:// but I 
haven't done any further investigations in that direction.
> 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?
For the current implementation I decided to use the "string 
concatenation" way. The mailboxes will be completely hierarchy agnostic. 
I'm quite happy with that decision so far.
This way the mailbox does not need a connection to the store and there 
is a central point where the mapping is done.

There are even more good reasons:
 * IMAP does not require to fetch child or parent mailboxes
 * There is no efficient possibility to store hierarchies into a RDBMS


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

View raw message