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<d...@tim-erwin.de>:
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 e...@localhost.net user.
The created dir is "/var/Maildirs/eric/...". We may have user clash if
let's say e...@otherdomain.net 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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
