Re: BasicMailboxSession (aka MessageRepository)

[Stefano Bagnara <ap...@bago.org>]

I just noticed I never replied to this.
+1 to everything.

The plan fits perfectly in our step-by-step "revolution by evolution".

I see you already created a new branch to work on this! Cool!

Stefano

Joachim Draeger wrote:
> 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 
> agnostic.
> 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
> 
> Joachim



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