Re: Imap status
On Sun, Jun 12, 2011 at 8:53 AM, Ioan Eugen Stan wrote: > 2011/6/11 Eric Charles : >> 0.2.x, of course :) >> I will add a table on the imap web site with the supported extension per >> version. >> >> Sure, we can rely for now on dovecot testsuite. For the "how to test", we >> can simply link for now to http://www.imapwiki.org/ImapTest >> In the long run, mailbox-integration-tests could be enhanced. > > In my opinion, integration tests are good for developers while > external tests are good for users. So I think there should be both. continuous delivery Robert - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Imap status
2011/6/11 Eric Charles : > 0.2.x, of course :) > I will add a table on the imap web site with the supported extension per > version. > > Sure, we can rely for now on dovecot testsuite. For the "how to test", we > can simply link for now to http://www.imapwiki.org/ImapTest > In the long run, mailbox-integration-tests could be enhanced. In my opinion, integration tests are good for developers while external tests are good for users. So I think there should be both. -- Ioan Eugen Stan http://ieugen.blogspot.com/ - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Imap status
Thats right. I included the not yet released imap version in the beta to speed up things. thats why I said that we first need to release the imap version . bye Norman Am Sonntag, 12. Juni 2011 schrieb Eric Charles : > Hi, > > I'm a bit lost... > > The vote for imap-0.2.1 is open wich is coherent with [1] (only 0.2 is > release) > > However, the beta1 proposal (I'm running fine now btw) refers and contains a > imap-0.2.1 which is not yet released. > > I must miss something... > Tks, > - Eric > > [1] > https://repository.apache.org/content/repositories/releases/org/apache/james/apache-james-imap-api/ > > > On 11/06/11 13:01, Eric Charles wrote: > > 0.2.x, of course :) > I will add a table on the imap web site with the supported extension per > version. > > Sure, we can rely for now on dovecot testsuite. For the "how to test", > we can simply link for now to http://www.imapwiki.org/ImapTest > In the long run, mailbox-integration-tests could be enhanced. > > Tks, > - Eric > > > On 11/06/11 12:53, Norman Maurer wrote: > > Hi there, > > first of its 0.2 and 0.2.1 ;) For the rest see inside > > Am Samstag, 11. Juni 2011 schrieb Eric Charles: > > Hi, > > This weekend, I will test server-beta1 (ok so far), imap-2.0.1 and > will update documentation for the releases. > > Is the following correct (Norman was so fast I could even not follow > him :) > > IMAP4rev1 2.0 > > 0.2 > > > LITERAL+ 2.0 > > 0.2 > > > CHILDREN > > 0.2 > > > I18NLEVEL=1 2.0.1 > > 0.2.1 > > > WITHIN 2.0.1 > > 0.2 > > > ESEARCH 2.0.1 > > 0.2.1 > > > SEARCHRES 2.0.1 > > 0.2.1 > > > IDLE 2.0 > > 0.2 > > > NAMESPACE 2.0 > > 0.2 > > > UIDPLUS 2.0 > > 0.2 > > > UNSELECT 2.0.1 > > 0.2 > > > AUTH=PLAIN 2.0.1 > > 0.2.1 > > > SASL-IR 2.0.1 > > 0.2.1 > > > ENABLE 2.0.1 > > 0.2.1 > > > > Also, are there specific tests for all these imap extensions (what is > the test coverage ?). > > > > You can most of them test with dovecot's imaptest. I will write an > email later and explain how > > > Tks, > - Eric > > - > 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 > > > > > - > 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
Re: Imap status
Hi, I'm a bit lost... The vote for imap-0.2.1 is open wich is coherent with [1] (only 0.2 is release) However, the beta1 proposal (I'm running fine now btw) refers and contains a imap-0.2.1 which is not yet released. I must miss something... Tks, - Eric [1] https://repository.apache.org/content/repositories/releases/org/apache/james/apache-james-imap-api/ On 11/06/11 13:01, Eric Charles wrote: 0.2.x, of course :) I will add a table on the imap web site with the supported extension per version. Sure, we can rely for now on dovecot testsuite. For the "how to test", we can simply link for now to http://www.imapwiki.org/ImapTest In the long run, mailbox-integration-tests could be enhanced. Tks, - Eric On 11/06/11 12:53, Norman Maurer wrote: Hi there, first of its 0.2 and 0.2.1 ;) For the rest see inside Am Samstag, 11. Juni 2011 schrieb Eric Charles: Hi, This weekend, I will test server-beta1 (ok so far), imap-2.0.1 and will update documentation for the releases. Is the following correct (Norman was so fast I could even not follow him :) IMAP4rev1 2.0 0.2 LITERAL+ 2.0 0.2 CHILDREN 0.2 I18NLEVEL=1 2.0.1 0.2.1 WITHIN 2.0.1 0.2 ESEARCH 2.0.1 0.2.1 SEARCHRES 2.0.1 0.2.1 IDLE 2.0 0.2 NAMESPACE 2.0 0.2 UIDPLUS 2.0 0.2 UNSELECT 2.0.1 0.2 AUTH=PLAIN 2.0.1 0.2.1 SASL-IR 2.0.1 0.2.1 ENABLE 2.0.1 0.2.1 Also, are there specific tests for all these imap extensions (what is the test coverage ?). You can most of them test with dovecot's imaptest. I will write an email later and explain how Tks, - Eric - 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 - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Imap status
0.2.x, of course :) I will add a table on the imap web site with the supported extension per version. Sure, we can rely for now on dovecot testsuite. For the "how to test", we can simply link for now to http://www.imapwiki.org/ImapTest In the long run, mailbox-integration-tests could be enhanced. Tks, - Eric On 11/06/11 12:53, Norman Maurer wrote: Hi there, first of its 0.2 and 0.2.1 ;) For the rest see inside Am Samstag, 11. Juni 2011 schrieb Eric Charles: Hi, This weekend, I will test server-beta1 (ok so far), imap-2.0.1 and will update documentation for the releases. Is the following correct (Norman was so fast I could even not follow him :) IMAP4rev1 2.0 0.2 LITERAL+ 2.0 0.2 CHILDREN 0.2 I18NLEVEL=1 2.0.1 0.2.1 WITHIN 2.0.1 0.2 ESEARCH 2.0.1 0.2.1 SEARCHRES 2.0.1 0.2.1 IDLE 2.0 0.2 NAMESPACE 2.0 0.2 UIDPLUS 2.0 0.2 UNSELECT 2.0.1 0.2 AUTH=PLAIN 2.0.1 0.2.1 SASL-IR 2.0.1 0.2.1 ENABLE 2.0.1 0.2.1 Also, are there specific tests for all these imap extensions (what is the test coverage ?). You can most of them test with dovecot's imaptest. I will write an email later and explain how Tks, - Eric - 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
Re: Imap status
Hi there, first of its 0.2 and 0.2.1 ;) For the rest see inside Am Samstag, 11. Juni 2011 schrieb Eric Charles : > Hi, > > This weekend, I will test server-beta1 (ok so far), imap-2.0.1 and will > update documentation for the releases. > > Is the following correct (Norman was so fast I could even not follow him :) > > IMAP4rev1 2.0 0.2 > LITERAL+ 2.0 0.2 > CHILDREN 0.2 > I18NLEVEL=1 2.0.1 0.2.1 > WITHIN 2.0.1 0.2 > ESEARCH 2.0.1 0.2.1 > SEARCHRES 2.0.1 0.2.1 > IDLE 2.0 0.2 > NAMESPACE 2.0 0.2 > UIDPLUS 2.0 0.2 > UNSELECT 2.0.1 0.2 > AUTH=PLAIN 2.0.1 0.2.1 > SASL-IR 2.0.1 0.2.1 > ENABLE 2.0.1 0.2.1 > > Also, are there specific tests for all these imap extensions (what is the > test coverage ?). > You can most of them test with dovecot's imaptest. I will write an email later and explain how > Tks, > - Eric > > - > 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
Re: Imap status
On Wed, Jun 4, 2008 at 2:25 PM, Zsombor <[EMAIL PROTECTED]> wrote: > On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin < > [EMAIL PROTECTED]> wrote: > >> On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <[EMAIL PROTECTED]> wrote: >> > Robert Burrell Donkin pisze: >> >> >> >> On 6/4/08, Ihsiak <[EMAIL PROTECTED]> wrote: >> >>> >> >>> Hello >> >> >> >> Hi >> >> >> >>> I am part of a team that works on integrating James with webbased >> >>> mailing solution. So far, we have sucessfully developed integration for >> >>> smtp and pop3, and now we are going to work on IMAP. I know that >> current >> >>> IMAP is not production ready - yet, so we want to work closely with you >> >>> and make it better (for you) and usefull (for us). If we get >> permission, >> >>> therewill be probably 2 persons available for about 2-3 months for that >> >>> project. But before we get to that I need to know what's current stare >> >>> of IMAP code, and what areas requies work. Can anyone describe it to >> me? >> >> >> >> There are currently two IMAP implementations on trunk. One has a >> >> straightforward design and is currently unmaintained. The second is an >> >> experimental rewrite. This code is under active development but is >> >> difficult to work with (my interest is in advanced high performance >> >> mail architectures and it's an in-place rewrite since I use it for my >> >> mail). >> >> >> >> The main implementation is incomplete, buggy and leaks memory. The new >> >> implementation works ok with the clients I use and is very close to >> >> being feature complete. But the original should be fixable by >> >> cross-porting. >> >> Which version interests you? >> > >> > Definitely the second one (we don't want to duplicate integration work, >> and >> > do "waste" bug fixing on the old code, and then on the new one). >> >> good. i'll talk only the second from now on. >> >> > We should be able to donate two persons to work on that project - can you >> > estimate how long it would take to complete "feature complete" version >> >> IMAP (as a specification) is interesting :-/ >> >> 4rev1 is specified by RFC2060 and again in RFC3501. the major >> difference is that STARTTLS is not supported by RFC2060 but is >> mandated by RFC3501. AIUI newish clients all use RFC3501, ancient >> clients use RFC3501. IMAPS works but STARTTLS is to be implemented. >> >> STARTTLS should be straight forward but ideally want to push generic >> support into the JAMES socket handling layer. any volunteers? >> > > A year ago I've made a mina based IMAPS/IMAP module, for the old, > straightforward design. > If there is some interest to merge, I can rework it, for the more difficult > design - if there is no plan to simpify/redesign that :) hoped you might say that :-) but i was planning to wait to ask until we're ready to review and rework the data access and socket APIs. before we turn to that, i think that functional compatibility test needs to be completed. this will allow safer refactoring without regression. that's pretty close now. > Currently I dont > know what were my greatest concern with it. the old version crashes some older versions of Mail, Thunderbird and Evolution > STARTTLS support is documented > in the mina site, so I doesn't have to be too difficult. i agree that STARTTLS should be straightforward. i thin k that the switching needs to be socket API (eg mina). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imap status
On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin < [EMAIL PROTECTED]> wrote: > On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <[EMAIL PROTECTED]> wrote: > > Robert Burrell Donkin pisze: > >> > >> On 6/4/08, Ihsiak <[EMAIL PROTECTED]> wrote: > >>> > >>> Hello > >> > >> Hi > >> > >>> I am part of a team that works on integrating James with webbased > >>> mailing solution. So far, we have sucessfully developed integration for > >>> smtp and pop3, and now we are going to work on IMAP. I know that > current > >>> IMAP is not production ready - yet, so we want to work closely with you > >>> and make it better (for you) and usefull (for us). If we get > permission, > >>> therewill be probably 2 persons available for about 2-3 months for that > >>> project. But before we get to that I need to know what's current stare > >>> of IMAP code, and what areas requies work. Can anyone describe it to > me? > >> > >> There are currently two IMAP implementations on trunk. One has a > >> straightforward design and is currently unmaintained. The second is an > >> experimental rewrite. This code is under active development but is > >> difficult to work with (my interest is in advanced high performance > >> mail architectures and it's an in-place rewrite since I use it for my > >> mail). > >> > >> The main implementation is incomplete, buggy and leaks memory. The new > >> implementation works ok with the clients I use and is very close to > >> being feature complete. But the original should be fixable by > >> cross-porting. > >> Which version interests you? > > > > Definitely the second one (we don't want to duplicate integration work, > and > > do "waste" bug fixing on the old code, and then on the new one). > > good. i'll talk only the second from now on. > > > We should be able to donate two persons to work on that project - can you > > estimate how long it would take to complete "feature complete" version > > IMAP (as a specification) is interesting :-/ > > 4rev1 is specified by RFC2060 and again in RFC3501. the major > difference is that STARTTLS is not supported by RFC2060 but is > mandated by RFC3501. AIUI newish clients all use RFC3501, ancient > clients use RFC3501. IMAPS works but STARTTLS is to be implemented. > > STARTTLS should be straight forward but ideally want to push generic > support into the JAMES socket handling layer. any volunteers? > A year ago I've made a mina based IMAPS/IMAP module, for the old, straightforward design. If there is some interest to merge, I can rework it, for the more difficult design - if there is no plan to simpify/redesign that :) Currently I dont know what were my greatest concern with it. STARTTLS support is documented in the mina site, so I doesn't have to be too difficult. You can look into at http://code.google.com/p/james-imap-storage/source/browse/trunk/imap-mina/ BR, Zsombor > everything else is just about feature complete but with some areas of > buggy code which are yet to be rewritten (mainly in FETCH and APPEND). > the biggest remaining effort is going to be proving the implementation > works. this requires improving the functional test suite (and fixing > all bugs found), in particular by simulating a variety of clients. > > but feature complete is a way from being production ready. the current > backend needs a complete rewrite, for example. > > IMAP also has quite a number of additional RFCs which define extra features > Especially if you want to target limited devices, smartphones/pdas. BR, Zsombor
Re: Imap status
On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin pisze: >> >> On 6/4/08, Ihsiak <[EMAIL PROTECTED]> wrote: >>> >>> Hello >> >> Hi >> >>> I am part of a team that works on integrating James with webbased >>> mailing solution. So far, we have sucessfully developed integration for >>> smtp and pop3, and now we are going to work on IMAP. I know that current >>> IMAP is not production ready - yet, so we want to work closely with you >>> and make it better (for you) and usefull (for us). If we get permission, >>> therewill be probably 2 persons available for about 2-3 months for that >>> project. But before we get to that I need to know what's current stare >>> of IMAP code, and what areas requies work. Can anyone describe it to me? >> >> There are currently two IMAP implementations on trunk. One has a >> straightforward design and is currently unmaintained. The second is an >> experimental rewrite. This code is under active development but is >> difficult to work with (my interest is in advanced high performance >> mail architectures and it's an in-place rewrite since I use it for my >> mail). >> >> The main implementation is incomplete, buggy and leaks memory. The new >> implementation works ok with the clients I use and is very close to >> being feature complete. But the original should be fixable by >> cross-porting. >> Which version interests you? > > Definitely the second one (we don't want to duplicate integration work, and > do "waste" bug fixing on the old code, and then on the new one). good. i'll talk only the second from now on. > We should be able to donate two persons to work on that project - can you > estimate how long it would take to complete "feature complete" version IMAP (as a specification) is interesting :-/ 4rev1 is specified by RFC2060 and again in RFC3501. the major difference is that STARTTLS is not supported by RFC2060 but is mandated by RFC3501. AIUI newish clients all use RFC3501, ancient clients use RFC3501. IMAPS works but STARTTLS is to be implemented. STARTTLS should be straight forward but ideally want to push generic support into the JAMES socket handling layer. any volunteers? everything else is just about feature complete but with some areas of buggy code which are yet to be rewritten (mainly in FETCH and APPEND). the biggest remaining effort is going to be proving the implementation works. this requires improving the functional test suite (and fixing all bugs found), in particular by simulating a variety of clients. but feature complete is a way from being production ready. the current backend needs a complete rewrite, for example. IMAP also has quite a number of additional RFCs which define extra features > (count us too, but keep in mind that we have to get familiar with the code > first). the developers on IMAP are volunteers and many work on multiple projects. JAMES is also into an intensive cycle of releasing components which is my personal priority ATM. so estimates and deadlines are difficult. there's also the question of what production readiness means: running live on the internet is quite different from running on a intranet protected by a firewall; serving a few dozen users is very different from serving thousands. but i think that 2 extra developers should be able to achieve a reasonably good IMAP over 2-3 months. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imap status
Robert Burrell Donkin pisze: On 6/4/08, Ihsiak <[EMAIL PROTECTED]> wrote: Hello Hi I am part of a team that works on integrating James with webbased mailing solution. So far, we have sucessfully developed integration for smtp and pop3, and now we are going to work on IMAP. I know that current IMAP is not production ready - yet, so we want to work closely with you and make it better (for you) and usefull (for us). If we get permission, therewill be probably 2 persons available for about 2-3 months for that project. But before we get to that I need to know what's current stare of IMAP code, and what areas requies work. Can anyone describe it to me? There are currently two IMAP implementations on trunk. One has a straightforward design and is currently unmaintained. The second is an experimental rewrite. This code is under active development but is difficult to work with (my interest is in advanced high performance mail architectures and it's an in-place rewrite since I use it for my mail). The main implementation is incomplete, buggy and leaks memory. The new implementation works ok with the clients I use and is very close to being feature complete. But the original should be fixable by cross-porting. Which version interests you? Definitely the second one (we don't want to duplicate integration work, and do "waste" bug fixing on the old code, and then on the new one). We should be able to donate two persons to work on that project - can you estimate how long it would take to complete "feature complete" version (count us too, but keep in mind that we have to get familiar with the code first). -- regards Bartosz Tomasik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imap status
On 6/4/08, Ihsiak <[EMAIL PROTECTED]> wrote: > Hello Hi > I am part of a team that works on integrating James with webbased > mailing solution. So far, we have sucessfully developed integration for > smtp and pop3, and now we are going to work on IMAP. I know that current > IMAP is not production ready - yet, so we want to work closely with you > and make it better (for you) and usefull (for us). If we get permission, > therewill be probably 2 persons available for about 2-3 months for that > project. But before we get to that I need to know what's current stare > of IMAP code, and what areas requies work. Can anyone describe it to me? There are currently two IMAP implementations on trunk. One has a straightforward design and is currently unmaintained. The second is an experimental rewrite. This code is under active development but is difficult to work with (my interest is in advanced high performance mail architectures and it's an in-place rewrite since I use it for my mail). The main implementation is incomplete, buggy and leaks memory. The new implementation works ok with the clients I use and is very close to being feature complete. But the original should be fixable by cross-porting. Which version interests you? Robert > > thx > > -- > regards > Bartosz Tomasik > --- > 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]
Re: Imap status history
Hi Stefano, Am Mittwoch, den 11.10.2006, 18:58 +0200 schrieb Stefano Bagnara: > I think we'll probably want to do many refactorings on this new stuff, > but I think we should merge to trunk as soon as possible. +1 > If we have the code in trunk it will be more probable that people will > take the time to work on it. > > I expect to do changes/refactoring to that part without too much > discussions. As always: commit then review. If anyone think a given > refactoring is a step-back instead of a step-forward will just raise his > own voice. It was always clear to me that the "deeper" integration has to be managed by someone who has a deep insight into James. So please go on! :-) And I understand that raising the API discussion now does not help much bringing it to trunk. Because I may be blind for James integration, please ask when I can help you. But before the API discussion I won't go on improving much the current implementation. Apart from obvious bugs, of course, so please keep on reporting! BTW I feel completely fine with CTR! If the changes are not too substantial it's much easier to follow than long discussions. Joachim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imap status history
Joachim Draeger schrieb: > Hi! > > Since original imap2 branch from apache svn I did the following: > > 1. integration with current James trunk > > At the moment a bit weird. It is based on AbstractJamesService which has > changed a lot since the original branch. ImapHandler does not extend > AbstractJamesHandler at the moment. > We should change this when the handler api2 is complete... Otherwise we have to do the work 2 times.. > 2. new unit tests > > Because I couldn't get the original tests to run I decided to start > writing my own ones. This helped me getting my hands in the imap code. > Maybe we are able to reanimate some original tests, if that makes > sense. > Well, i think tests are good every time.. But you allready publish good tests.. so i think we can stay with it like it is at the moment. > 3. minor bugfixing > > 4. removed original ImapStore interfaces that were implemented by the > in-memory-store. > > The original backend interfaces are grown interfaces developed at the > same time the imap code was done. > Some refactoring was obviously needed and I decided to rewrite the > interfaces from scratch. After I did the Torque-prototype implementation > I integrated the new API with the imap code. > > Sounds good > Joachim > > P.S. more to the mailboxmanager in the next thread > > > bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imap status history
Joachim Draeger wrote: Hi! Since original imap2 branch from apache svn I did the following: 1. integration with current James trunk At the moment a bit weird. It is based on AbstractJamesService which has changed a lot since the original branch. ImapHandler does not extend AbstractJamesHandler at the moment. I saw. I think we'll plan the port to the "handlerapi2" just after we'll have approved the currently-in-branch proposal. I think at that moment we'll update all of our handlers to follow that pattern (or at least we'll try to). 2. new unit tests Because I couldn't get the original tests to run I decided to start writing my own ones. This helped me getting my hands in the imap code. Maybe we are able to reanimate some original tests, if that makes sense. Imho it does not make sense: your tests already cover much more than the original one. 3. minor bugfixing ok 4. removed original ImapStore interfaces that were implemented by the in-memory-store. The original backend interfaces are grown interfaces developed at the same time the imap code was done. Some refactoring was obviously needed and I decided to rewrite the interfaces from scratch. After I did the Torque-prototype implementation I integrated the new API with the imap code. I think we'll probably want to do many refactorings on this new stuff, but I think we should merge to trunk as soon as possible. If we have the code in trunk it will be more probable that people will take the time to work on it. I already started studying some of the code to understand what I can easily refactor to better match other james components and I did already few minor fixes. I expect to do changes/refactoring to that part without too much discussions. As always: commit then review. If anyone think a given refactoring is a step-back instead of a step-forward will just raise his own voice. Btw at the moment I don't have too much time: I will open JIRA issues for tasks that I think are needed on that part. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: IMAP status
Jason Webb wrote:
> > -Original Message-
> > From: Stefano Bagnara [mailto:[EMAIL PROTECTED]
> > Sent: 26 October 2005 17:26
> > To: 'James Developers List'
> > Subject: Re: Re: IMAP status
> >
> >
> > In my current james (patched trunk) I have this interface for
> > MessageRepository:
> >
> > /**
> > * Interface for a Repository to store MimeMessage.
> > *
> > *
> > */
> > public interface MessageRepository {
> // I'd also add
> void delete(); // Remove the repository completely
>
> void rename(String newName); //move or rename the repository
> // Copy is not required for IMAP as it can be
> implemented in other
> ways
>
> // I'm fairly indifferent to how we get the child reps
> // we just need some way to get hold of them
> MessageRepository[] getChildren();
>
> void addChild(MessageRepository repository);
>
>
> > }
Would we want a MessageRepository to be able to rename or delete itself at
the public interface level? This might be how it happens at the
implementation level, but its generally safer and easier to have the parent
instigate these actions. This enables the parent to update its references
without requiring some kind of eventing mechanism and enbles the enforcement
of rules in the context of the parent. The drawback is that we would need a
null top node to perform these actions on the root MessageRepository. In
truth its hard to come up with a case for either renaming or deleting the
root, so I think this is a mute point and no drawback at all.
>
> There would then be a separate interface for IMAP repositories to wrap
> things like access to UIDs and MSNs.
Do you mean an interface that extends the basic one described above? If so,
I can see us digging a hole for ourselves as we could end up with just some
repositories supporting IMAP. I would rather go for a single interface
supporting the set of operations we require or a scheme whereby we add
getter/setters for generic named attributes, e.g. void setAttribute(String
aName, Object aValue) / Object getAttribute(aName). The latter approach
would enable any number of additional attributes to be added for any number
of repository types.
> >
> > And then I create a MessageRepositoryWrapper that provide a
> > MessageRepository over an "old" (currently used)
> MailRepository. This way
> > I've been able to upgrade to my interfaces while keeping
> the current data
> > (file/db structure/data).
> >
> > The interface is really slim: we just need to decide wether to keep
> > "MimeMessage" or use a "Stream" instead.
> > Maybe the StreamRepository from cornerstone already
> implements a similar
> > interface. We already use it in the SMTPHandler to store
> the incoming
> > message before sending it to the spooler.
I don't see MimeMessage and Stream as mutually exclusive, we could have
interfaces for each. Stream is a layer below MimeMessage and any other high
level layer we choose to introduce. We could implement utility adapters for
transforming between each high level layer and the Stream layer. We would
have one or more interfaces for high level layers such as MimeMessage and a
single low level interface for Stream.
-- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
Jason Webb wrote: // I'm fairly indifferent to how we get the child reps // we just need some way to get hold of them MessageRepository[] getChildren(); void addChild(MessageRepository repository); I guess we're holding that 'MessageRepository == Folder' ? Maybe MessageRepository could be like the 'Store' class in the Javamail API, or the 'IMsgStore' class in MAPI; a server wide object that holds the root folder. There would then be a separate interface for IMAP repositories to wrap things like access to UIDs and MSNs. Or those could be also be included in the MessageRepository interface? Stubbed in implementations that do not need them, eg. A repository that does not support IMAP. There could be separation between parameters that *have* to have direct access for speed, eg. getUID() maybe, and others that can be accessed via a generic 'getParameter( Key, Value)' function on repository objects. I think that the generic getParameter method can still be very fast especially if the repository implementation is smart enough to cache certain parameters. Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
Stefano Bagnara wrote: > We already have this interface: MailRepository. We simply should deprecate the MailRepository (we can always use the SpoolRepository instead) and create a new MessageRepository interface. Thanks for clarifying those relationships, I have been wondering about those issues. In my current james (patched trunk) I have this interface for MessageRepository: This is interesting. You're using a Hashtable type interface with just key/value pairs instead of a message/folders type API. Will the classes that inherit from this object be responsible for creating and maintaining folder structure? Won't that have to be serialized somehow? Also it seems like the entire message will have to be read into memory before an attribute, eg. size, to be determined. How do you work around this? Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: IMAP status
> -Original Message-
> From: Stefano Bagnara [mailto:[EMAIL PROTECTED]
> Sent: 26 October 2005 17:26
> To: 'James Developers List'
> Subject: Re: Re: IMAP status
>
> > Users are going to want to extend James' Message Store Model.
> > A single interface that acts like a "Virtual File System" of
> > soughts will make it easier for them.
> > This interface would deal with only the serialization and
> > retrival of data.
>
> We already have this interface: MailRepository.
> We simply should deprecate the MailRepository (we can always use the
> SpoolRepository instead) and create a new MessageRepository interface.
>
> > Maybe we can get it to the point that a user writing a single
> > class implementing the MailStore interface is all that is
> > needed to port James to a new database system or file format?
> > As with some other message APIs?
>
> MailStore has been removed in the current trunk because it was not
> necessary.
> We already have "Store" as the main object (let's say "repositories")
> factory interface.
>
>
> In my current james (patched trunk) I have this interface for
> MessageRepository:
>
> /**
> * Interface for a Repository to store MimeMessage.
> *
> *
> */
> public interface MessageRepository {
>
> /**
> * Stores a message in this repository.
> *
> * @param mc the message to store
> * @return the key to later retrieve this message
> */
> String store(MimeMessage mc) throws MessagingException;
>
> /**
> * List string keys of messages in repository.
> *
> * @return an Iterator over the list of keys in the
> repository
> *
> */
> Set keySet() throws MessagingException;
>
> /**
> * List key,message touples in repository.
> *
> * @return a Set of Map.Entry representing
> * messagekey => MimeMessage
> */
> Set entrySet() throws MessagingException;
>
> /**
> * Retrieves a message given a key. At the moment, keys can be
> obtained
> * from list()
> *
> * @param key the key of the message to retrieve
> * @return the mail corresponding to this key, null if none exists
> */
> MimeMessage retrieve(String key) throws MessagingException;
>
> /**
> * Removes a message identified by key.
> *
> * @param key the key of the message to be removed from the repository
> */
> void remove(String key) throws MessagingException;
>
// I'd also add
void delete(); // Remove the repository completely
void rename(String newName); //move or rename the repository
// Copy is not required for IMAP as it can be implemented in other
ways
// I'm fairly indifferent to how we get the child reps
// we just need some way to get hold of them
MessageRepository[] getChildren();
void addChild(MessageRepository repository);
> }
There would then be a separate interface for IMAP repositories to wrap
things like access to UIDs and MSNs.
>
> And then I create a MessageRepositoryWrapper that provide a
> MessageRepository over an "old" (currently used) MailRepository. This way
> I've been able to upgrade to my interfaces while keeping the current data
> (file/db structure/data).
>
> The interface is really slim: we just need to decide wether to keep
> "MimeMessage" or use a "Stream" instead.
> Maybe the StreamRepository from cornerstone already implements a similar
> interface. We already use it in the SMTPHandler to store the incoming
> message before sending it to the spooler.
>
> Stefano
>
>
> -
> 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]
Re: Re: IMAP status
> Users are going to want to extend James' Message Store Model.
> A single interface that acts like a "Virtual File System" of
> soughts will make it easier for them.
> This interface would deal with only the serialization and
> retrival of data.
We already have this interface: MailRepository.
We simply should deprecate the MailRepository (we can always use the
SpoolRepository instead) and create a new MessageRepository interface.
> Maybe we can get it to the point that a user writing a single
> class implementing the MailStore interface is all that is
> needed to port James to a new database system or file format?
> As with some other message APIs?
MailStore has been removed in the current trunk because it was not
necessary.
We already have "Store" as the main object (let's say "repositories")
factory interface.
In my current james (patched trunk) I have this interface for
MessageRepository:
/**
* Interface for a Repository to store MimeMessage.
*
*
*/
public interface MessageRepository {
/**
* Stores a message in this repository.
*
* @param mc the message to store
* @return the key to later retrieve this message
*/
String store(MimeMessage mc) throws MessagingException;
/**
* List string keys of messages in repository.
*
* @return an Iterator over the list of keys in the
repository
*
*/
Set keySet() throws MessagingException;
/**
* List key,message touples in repository.
*
* @return a Set of Map.Entry representing
* messagekey => MimeMessage
*/
Set entrySet() throws MessagingException;
/**
* Retrieves a message given a key. At the moment, keys can be obtained
* from list()
*
* @param key the key of the message to retrieve
* @return the mail corresponding to this key, null if none exists
*/
MimeMessage retrieve(String key) throws MessagingException;
/**
* Removes a message identified by key.
*
* @param key the key of the message to be removed from the repository
*/
void remove(String key) throws MessagingException;
}
And then I create a MessageRepositoryWrapper that provide a
MessageRepository over an "old" (currently used) MailRepository. This way
I've been able to upgrade to my interfaces while keeping the current data
(file/db structure/data).
The interface is really slim: we just need to decide wether to keep
"MimeMessage" or use a "Stream" instead.
Maybe the StreamRepository from cornerstone already implements a similar
interface. We already use it in the SMTPHandler to store the incoming
message before sending it to the spooler.
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
Steve Brewin wrote: Can we agree on org.apache.james.xxx interfaces that capture the behaviour we need a repository to provide? Jason's existing work has surfaced most of the requirements. We can then write adapters for specific implementations such as Javamail or whatever else we agree upon, even change our minds about the implementation Agreed, 110% Even when the Javamail/MIME4J/Etc. argument is settled there are going to be cases where another mail store implementation is much better suited for a particular environment. Users are going to want to extend James' Message Store Model. A single interface that acts like a "Virtual File System" of soughts will make it easier for them. This interface would deal with only the serialization and retrival of data. Maybe we can get it to the point that a user writing a single class implementing the MailStore interface is all that is needed to port James to a new database system or file format? As with some other message APIs? Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
Comments inline. Joe Cheng wrote: Serge Knystautas wrote: MIME4J is nowhere ready to be a replacement. It is a read-only API last I checked. Noel, you said on server-users@ that you thought IMAP allowed modification of Messages (using your definition). To my knowledge, this is not the case (someone please correct me if I'm wrong). What IMAP does allow you to do is add new messages to a mailbox, which POP of course does not. On already existing messages you can only change flags which fall under Mail, not Message. You are correct. With the APPEND command, you can add new messages to a specific Mailbox. The way some systems make it look like changing a message is by APPEND'ing a message with all the same data including changes, and deleting the previous one. I have been thinking of using this feature to create an IMAPNotes program that would allow storage of Notes with Edit/Delete/New functionality using IMAP as the store. JavaMail does make this feature look as though it is editing the same message though so I can understand the confusion. [snip] -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
Serge Knystautas wrote: MIME4J is nowhere ready to be a replacement. It is a read-only API last I checked. Noel, you said on server-users@ that you thought IMAP allowed modification of Messages (using your definition). To my knowledge, this is not the case (someone please correct me if I'm wrong). What IMAP does allow you to do is add new messages to a mailbox, which POP of course does not. On already existing messages you can only change flags which fall under Mail, not Message. That's why when working on my own IMAP server I didn't feel the need to make MIME4J support message mutation--it's only even needed in James for mailets, which was out of scope for my project. If mailets only apply during the delivery phase, could you just use JavaMail at that point (for the mailets that needed it) and then MIME4J everywhere else? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
Steve Brewin wrote: Steve Brewin wrote: Might we move this discussion to [EMAIL PROTECTED] :-) Good idea! Sent this to server-dev. Will comment there. Can we agree on org.apache.james.xxx interfaces that capture the behaviour we need a repository to provide? Jason's existing work has surfaced most of the requirements. We can then write adapters for specific implementations such as Javamail or whatever else we agree upon, even change our minds about the implementation in the future without breaking everyones good work. In the meantime, the blocked IMAP development could proceed, writing to these interfaces and using mock implementations. This would allow us to move forward. Of course, we would yet again hit a block if IMAP were done before a repository implementation. -- Steve This would be a great idea. Putting the Repository implementation in an interface design means we could also create MBox/MailDir/and Database backends more efficiently. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IMAP status
Steve Brewin wrote: > > > > Might we move this discussion to [EMAIL PROTECTED] :-) > > Good idea! > > Sent this to server-dev. Will comment there. Can we agree on org.apache.james.xxx interfaces that capture the behaviour we need a repository to provide? Jason's existing work has surfaced most of the requirements. We can then write adapters for specific implementations such as Javamail or whatever else we agree upon, even change our minds about the implementation in the future without breaking everyones good work. In the meantime, the blocked IMAP development could proceed, writing to these interfaces and using mock implementations. This would allow us to move forward. Of course, we would yet again hit a block if IMAP were done before a repository implementation. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IMAP status
Noel J. Bergman wrote: > I had suggested JavaMail, but when we all did further looking, it was > observed that JavaMail is not efficient for server storage, > it would tie us > to JavaMail, and worse to MimeMessage. We really want a > store that deals > with streams, from which we can easily construct a > MimeMessage on demand, > but can also use MIME4J without the overhead --- and parsing > issues --- of > the MimeMessage class. > > If those are solvable within the context of using JavaMail > for server-side > storage, fine. Alternatively, if we have a data store that > works for us and > can be put underneath JavaMail when/if we want to use > JavaMail, that's fine, > too. > > Might we move this discussion to [EMAIL PROTECTED] :-) Good idea! Sent this to server-dev. Will comment there. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP status
On 10/25/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > I had suggested JavaMail, but when we all did further looking, it was > observed that JavaMail is not efficient for server storage, it would tie us > to JavaMail, and worse to MimeMessage. We really want a store that deals > with streams, from which we can easily construct a MimeMessage on demand, > but can also use MIME4J without the overhead --- and parsing issues --- of > the MimeMessage class. > > If those are solvable within the context of using JavaMail for server-side > storage, fine. Alternatively, if we have a data store that works for us and > can be put underneath JavaMail when/if we want to use JavaMail, that's fine, > too. > > Might we move this discussion to [EMAIL PROTECTED] :-) Yes it would tie us to JavaMail, but we are already tied to JavaMail. We are already inefficient, so no sense (IMO) of at least taking advantage of what the API offers. IMHO what JavaMail is inefficient at is parsing and loading messages. Conversely what this proposal entails is using for what JavaMail is better (not great) at, i.e., working as a client to a mail store. MIME4J is nowhere ready to be a replacement. It is a read-only API last I checked. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: imap status
> This would make it possible for current mail stores to support > subfolders without modifications, using their destinationURL > configuration parameter. There are no subfolders in the current stores, although maildir is pending, so your example of: db://datasource/table/username/subfolder1/subfolder2/subfolderN means that "username/subfolder1/subfolder2/subfolderN" would the key. The fact that it looks like a hierarchical path is just an illusion. As I read 2060 Section 5, "interpretation of mailbox names is implementation-dependent" except for INBOX (case-insensitive). The RFC goes on to say that "mailbox names MUST be left-to-right hierarchical using a single character to separate levels of hierarchy", but leaves open the choice of separator character, with examples including '.', '\', and '/'. The LIST command tells the client what character is used for a separator for that particular path. They give an example of mapping NNTP newsgroups into the space, and those use '.' as the separator. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: imap status
> Either way, it would be a help to be able to query the delimiter(s) in use. > This would allow services that use folders, such as future Mailets and > jSieve to construct valid folder paths. Also, it would be good to have two > distinct exceptions. One for a malformed folder path, eg: > MalformedPathException, and one for non-existent folders, eg: > PathNotFoundException. This would enable a service to react differently to > the two distinct conditions. > I'm not yet fully familiar with mail stores, but I think "/" should be used as the delimiter and nothing else. This would make it possible for current mail stores to support subfolders without modifications, using their destinationURL configuration parameter. i.e.: for a JDBC subfolder of user's inbox, the destinationURL would be: db://datasource/table/username/subfolder1/subfolder2/subfolderN As you can see, The "username" folder is the user's INBOX. Any additional folders are thus subfolders of INBOX. I don't think this is a major issue. I know Cyrus and Courier-imap both work this way, may be others too. Even if "/" is used as the delimiter, the "." character should not be permitted in subfolder names. This is required if we want Maildir store support, on which I am currently working on. Dots in Maildirs are used for subfolders. Subfolders of inbox in a maildir are stored like this: Filesystem IMAP namespace Maildir//INBOX Maildir/.folder1/ /INBOX/folder1 Maildir/.folder1.folder2/ /INBOX/folder1/folder2 -- Cedric Veilleux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: imap status
Serge Knystautas wrote: > > The delimiter is usually "." or "/". It might break poorly written > > clients to use something else. > > Agreed, I've seen clients screwed by anything but / as the > delimiter and > would favor that. I'ld favour that as the default, possibly with the option to override to something else as part of the configuration. I say possibly as I haven't thought through the issues of changing the delimiter after mail has been written to the store. Dealing with this may be more expensive than the benefits it delivers. Either way, it would be a help to be able to query the delimiter(s) in use. This would allow services that use folders, such as future Mailets and jSieve to construct valid folder paths. Also, it would be good to have two distinct exceptions. One for a malformed folder path, eg: MalformedPathException, and one for non-existent folders, eg: PathNotFoundException. This would enable a service to react differently to the two distinct conditions. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: imap status
Cedric Veilleux wrote: There are no reserved or illegal characters. Each implementation can decide which delimiter character to use. The client will know the delimiter of the server by sending a LIST command with no additional argument. The server should then send ".INBOX" or "/INBOX" or whichever delimiter it uses followed by INBOX. See 6.3..8. LIST Command of rfc2060. The delimiter is usually "." or "/". It might break poorly written clients to use something else. Agreed, I've seen clients screwed by anything but / as the delimiter and would favor that. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: imap status
> To get IMAP working there are major 3 pieces of work that need to be > done: > 1) Add attribute support to users (for both file: and db:)- This is > required for storing mailbox settings etc > 2) Ensure that all current mail repositories support attributes for > mail - mbox does not for example :) Is it really necessary to be able to use any stores for imap? Enabling attributes from mbox style stores sounds like a lot of work. The messages need to be mangled to add additional headers for the attributes when saving and remove them when fetching a message. > 3) Link the repositories to the IMAP server > > My primary goal is to make sure that a user can use either POP3 or > IMAP4 when accessing their mailbox. The underlying storage mechanism > should not force a user to use a particular protocol only. Yes, that is very important. It is very common to see imap used to access mail through a webmail and POP to access it from a mail client. > I'm personally a bit busy at the moment, but by the time Noel has > finished the v3 update I will start rolling in some of my IMAP support > code. > > The IMAP protocol stack written by Darrell is my starting point. As > you may have noticed it only stores to memory at the moment. > > All I will do for implementation for the storage is use the existing > mail repository providers and add the mailbox name on the end as a > postfix. > For example (for use JW) > > Inbox (File JW) > James- (File JW.James) > Dev - (File JW.James.Dev) > Sent - (File JW.Sent) > Spam - (File JW.Spam) > > You get the idea :) > I won't be using '.' as the separator BTW. The IMAP rfc has some chars > that can't be used in folder names (I think) so I'll use those > instead. > There are no reserved or illegal characters. Each implementation can decide which delimiter character to use. The client will know the delimiter of the server by sending a LIST command with no additional argument. The server should then send ".INBOX" or "/INBOX" or whichever delimiter it uses followed by INBOX. See 6.3..8. LIST Command of rfc2060. The delimiter is usually "." or "/". It might break poorly written clients to use something else. -- Cédric Veilleux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: imap status
To get IMAP working there are major 3 pieces of work that need to be done: 1) Add attribute support to users (for both file: and db:)- This is required for storing mailbox settings etc 2) Ensure that all current mail repositories support attributes for mail - mbox does not for example :) 3) Link the repositories to the IMAP server My primary goal is to make sure that a user can use either POP3 or IMAP4 when accessing their mailbox. The underlying storage mechanism should not force a user to use a particular protocol only. I'm personally a bit busy at the moment, but by the time Noel has finished the v3 update I will start rolling in some of my IMAP support code. The IMAP protocol stack written by Darrell is my starting point. As you may have noticed it only stores to memory at the moment. All I will do for implementation for the storage is use the existing mail repository providers and add the mailbox name on the end as a postfix. For example (for use JW) Inbox (File JW) James - (File JW.James) Dev - (File JW.James.Dev) Sent - (File JW.Sent) Spam - (File JW.Spam) You get the idea :) I won't be using '.' as the separator BTW. The IMAP rfc has some chars that can't be used in folder names (I think) so I'll use those instead. -- Jason -Original Message-From: Cedric Veilleux [mailto:[EMAIL PROTECTED]Sent: 17 March 2004 22:44To: [EMAIL PROTECTED]Subject: imap statusHi, I am new to James. I have just been reviewing the imap proposals in CVS. Is anybody currently working on it? What is the current consensus on how to implement imap mail store? I've seen the org.apache.james.imapserver.store package, which I guess provides the features needed to implement the imap specs but is not compatible with the pop server.. Also, James needs MailRepository to deliver incoming mail to a user. The imap store does not provide this. What's the plan here? --Cédric Veilleux
