Stefano Bagnara schrieb: > 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.
+1 That sounds really intressting .. I had something simalar in mind , but never thought enough about it to make some clear statements. > > 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. Yes thats make sense.. of course.. And it whould maybe really simplify configuration of james.. > > 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 > > bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
