Joachim Draeger wrote:
Am Samstag, den 28.10.2006, 18:07 +0100 schrieb Danny Angus:
On 10/28/06, Joachim Draeger <[EMAIL PROTECTED]> 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
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.
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">
<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>
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" />
</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)
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?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
