Imap status history

[Joachim Draeger <jd...@joachim-draeger.de>]

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. 

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. 

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.


Joachim

P.S. more to the mailboxmanager in the next thread




   


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap status history

[Joachim Draeger <jd...@joachim-draeger.de>]

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap status history

[Stefano Bagnara <ap...@bago.org>]

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org