Hi Eric, I think you miss understood me. I think you are right about using file://var/ etc. But I would not use this in maildir module directly. Using this kind of "url" is specific to JAMES Server, so we should get rid of it there (Just extend the maildir classes).
Bye, Norman 2010/8/16 Eric Charles <[email protected]>: > Hi, > > With file:// , I was referring to james nomenclature (ex: "file://conf/..." > for files in james conf dir, "file://var/... for files in james var dir), > and not to the URI/URL patterns. > You can find plenty of this nomenclature in spring-beans.xml,... (ex: > file://conf/database.properties") > > The other James nomenclature is "classpath://. > We may remain with confusions with the James vs. URL/URI "file://", but i > think we could discuss a bit later in the frame of OSGI stuff,... > > "../var/..." can perfectly do the job now. > > Nice to read we can use %domain and %user variables. > May be the default in spring-beans.xml could be > "../var/Maildir/%domain/%user/Maildir" or whatever, so we know we can play > with domain / user structure. > > Tks, > > Eric > > > On 16/08/2010 08:26, Norman Maurer wrote: >> >> Hi, >> >> comments inside.. >> >> 2010/8/15 Tim-Christian Mundt<[email protected]>: >>> >>> Hi Eric, >>> >>> thanks a lot for checking out and for your kind comments. James' >>> Store-Architecture really makes it relatively easy (really relative) to >>> implement new Storages which is definitely a big plus for James. >>> >>> Changing the path is a good idea. However, introducing the scheme >>> (file://) would make the configuration more complicated and suggest that >>> other protocols would also work, right?. If its still better I can add >>> it, shouldn't be a big thing. >>> >> I think we should not add the scheme stuff. For JAMES Server we just >> need to subclass it and use the FileSystem interface for lookup the >> directory. No big deal ;) >> >> >>> The path is not really well documented, it needs to be in the config. It >>> can have three different variables: %user, %domain, %fulluser. You would >>> either use something like /Maildirs/%domain/%user/ or /Maildirs/% >>> fulluser >>> >> When thinking of vpopmail/courier-imap it use: >> ../%domain/%user/Maildir/ >> >> I think we should do the same.. >> >>> Regards >>> Tim >>> >>> Am Samstag, den 14.08.2010, 11:46 +0200 schrieb Eric Charles: >>>> >>>> Hi Tim, >>>> >>>> I checked-out, compiled, deployed and tested without any problem. >>>> Your MailDir store is working :) and generates the cur, new, tmp in my >>>> user directory. >>>> >>>> Last but not least, your code is really well structured and readable. >>>> You really made great job! >>>> >>>> Btw, we knew that James architecture was great open to alternative >>>> store, and you proved it. >>>> >>>> Quick comments: >>>> - I renamed /var/james/Maildirs/%user to ../var/Maildirs/%user (maybe >>>> should be file://var/...) to have relative paths to james deployment >>>> (more coherent with other stores) >>>> - I configured with JDBCDomainList and defined [email protected] user. >>>> The created dir is "/var/Maildirs/eric/...". We may have user clash if >>>> let's say [email protected] is defined. >>>> >>>> Tks, >>>> >>>> Eric >>>> >>>> >>>> On 08/13/2010 10:48 PM, Tim-Christian Mundt wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> last Monday was "pencils down" for the Google Summer of Code project. >>>>> The days till next Monday - the final dead line - are meant as time for >>>>> wrap up, testing, documentation and so on. >>>>> >>>>> Well, the new Maildir backend works. Until now it has just one >>>>> parameter >>>>> which is the path (with variables) where the Maildir folders should >>>>> reside. It works with pre-existing data from other servers or can build >>>>> up the data from scratch. The functional tests work with the exception >>>>> of "testSearchCombinations*" which is due to the fact that Maildir only >>>>> stores the _current_ date as internal date, not the one that is given >>>>> during append (which is perfectly valid for the RFC but not for the >>>>> tests). >>>>> >>>>> The code is attached to this mail and you can also find it in my >>>>> repository: svn://tim-erwin.de/maildir/trunk/maildir >>>>> Although GSOC is officially over, I'm still open to c&c and as soon as >>>>> the code is in the James SVN it's open to be teared apart anyways. >>>>> >>>>> Thanks for having me in this project. Special thanks to Norman who has >>>>> been a very helpful and nice to work with mentor. I'm sure this will >>>>> not >>>>> be the end of my James activities. >>>>> >>>>> Regards >>>>> Tim >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> Bye, >> Norman >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
