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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
