Imap contribution (Was: IMAP development)

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

Hi all,

 From the last status-update from Joachim, I understand that he's very 
near to have something working and that does not need changes on our 
main codebase.

Now that Joachim is a James Committer and has write access to SVN 
(Joachim: can you check your svn account works?) we have to decide what 
to do.

I think we should ask him to commit his work in server/sandbox/imap so 
we can review it and eventually merge it to trunk.

Imho we can let him skip the packaging and the documentation he did in 
past to post his work on JIRA, because he will do the work needed to 
integrate (very small work) it in trunk and then it will be much more 
easy for users that want to try IMAP as we'll bundle it in the default 
distribution.

I also think that it should be safe for us to include the code in the 
next-release: we'll decide wether to make it "public" (publicize it) or 
not in function of the stability and the architecture it will have when 
we'll make the next release (like we did for fastfail).

I expect that it will be included but disabled by default and marked as 
experimental in the next release due for 1st quarter 2007.

Do we need Joachim to sign a Software Grant 
(http://www.apache.org/licenses/software-grant.txt) for this?

Further inline comments follows:

Joachim Draeger wrote:
> A quick status of http://issues.apache.org/jira/browse/JAMES-502:
> 
> Because discussion of my API proposal published as 
> repository-proposal-3.zip at JIRA and on my website
> http://www.joachim-draeger.de/JamesImap/
> hibernated, I decided to start a prototype implementation which uses
> JDBC/Torque with MySQL or Derby, under the working title MailboxManager.
> Then I refactored the IMAP code to use the new API.  
> 
> Everything works quite well at the moment. I have unit tests for all
> basic operations.

I know that past unit tests where tightly linked to maildir: I also saw 
that you made steps since that time and now it seem you separated 
generic tests from maildir tests from mstor tests.
We can't incldue javamaildir stuff in our repository: does including all 
of the remaining things make sense? Is this already working?

> I just did the integration with current James trunk.
> I did it completely without changing current James code. Just putting,
> some jars into SAR-INF/lib and modifying assembly.xml.
> I soon publish it at JIRA, when I find the time to do the packaging with
> some documentation. (It always costs a lot of time so if you want to be up-to-date look at my svn)

As this is clearly a cost (time) I think we should skip this and you 
should itegrate it into the main codebase in the sandbox so we see what 
are the needed changes in svn notifications (international language :-) )
Once it will be integrated we'll need less documentation for 
users/developers to start working on it.

> For the impatient: 
> http://svn.joachim-draeger.de/repos/james/imap/
> http://svn.joachim-draeger.de/repos/james/mailboxmanager/
> 
> My ideas to the roadmap topic:
> 
>  - after publishing API with prototype running together with imap in James I hope for some review.
>  - maybe we are able to make some decisions then
>  - we have to decide if/how to integrate the code 
>  - for integration everything (sandbox/branch/product/trunk) is imaginable, because it does not interfere with existing code.
> 
> Joachim

I don't know if this roadmap is intended as a sorted list: in this case 
I would change the order because I think that integration should be the 
first task.

I think that we should use an agile approach to this task:
- commit it to sandbox (branch trunk, add your components, make 
configuration changes)
- "official" review/test from us
- when any "blocker" issue is solved merge it to trunk
- then I expect we can discuss and refactor it while a working version 
is in trunk: maybe someone will start short-living branches to show his 
ideas.

WDYT?

Stefano

PS: I reviewed Joachim's code few weeks ago, and there are few choices 
that I didn't like at first. But I think that blocking it with endless 
discussions will never bring us IMAP, so I'll wait to see the code 
working and integrated in trunk and I'll try to make my proposals about 
refactorings/api changes later.



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

Re: Imap contribution (Was: IMAP development)

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

Hi Stefano,

Am Freitag, den 06.10.2006, 12:38 +0200 schrieb Stefano Bagnara:

> Now that Joachim is a James Committer and has write access to SVN 
> (Joachim: can you check your svn account works?) we have to decide what 
> to do.

The account is there. Don't know whether the PMC has assigned me to
James resources yet. I'll actually see, when trying to commit
something. :-) 

> I think we should ask him to commit his work in server/sandbox/imap so 
> we can review it and eventually merge it to trunk.
> Imho we can let him skip the packaging and the documentation he did in 
> past to post his work on JIRA, because he will do the work needed to 
> integrate (very small work) it in trunk and then it will be much more 
> easy for users that want to try IMAP as we'll bundle it in the default 
> distribution.

I really would prefer committing it to sandbox instead of attaching to
Jira. Jira is great for single files and patches. Attaching a big zip
would be inconvenient for both sides. And maybe committers could
incorporate their suggestions while discussing by adding new/modified
interfaces to the API directly. Or add comments to the code where they
have remarks. Or even fixing bugs! ;-) I love SVN.

> I expect that it will be included but disabled by default and marked as 
> experimental in the next release due for 1st quarter 2007.

I hope so. Early user feedback would bring us a lot of benefits. 

> Do we need Joachim to sign a Software Grant 
> (http://www.apache.org/licenses/software-grant.txt) for this?

No, I don't think so. I never published it as a product somewhere else.
There are no other persons involved that are not apache committers.
And when I actually commit it my self into James-SVN it should be
enough. To exclude all possibility of doubt I could additionally attach
it to Jira doing a grant. ;-)

> > Everything works quite well at the moment. I have unit tests for all
> > basic operations.
> 
> I know that past unit tests where tightly linked to maildir: I also saw 
> that you made steps since that time and now it seem you separated 
> generic tests from maildir tests from mstor tests.
> We can't incldue javamaildir stuff in our repository: does including all 
> of the remaining things make sense? Is this already working?

The new API doesn't require any JavaMail stuff, apart from MimeMessage
and Flags. It's a 100% Torque/JDBC implementation. All additional
required libs have actually ASL.
There is no connection to javamailstore-mailrepository anymore. But I
still plan using JavamailStore together with mstor or javamaildir as a
an additional choice of backend. 
Another story is the possibility of creating a Javamailwrapper that
would allow other apps to use our JDBC backend.

> > My ideas to the roadmap topic:
> > 
> >  - after publishing API with prototype running together with imap in James I hope for some review.
> >  - maybe we are able to make some decisions then
> >  - we have to decide if/how to integrate the code 
> >  - for integration everything (sandbox/branch/product/trunk) is imaginable, because it does not interfere with existing code.

> I don't know if this roadmap is intended as a sorted list: in this case 
> I would change the order because I think that integration should be the 
> first task.

Also it was a quick note, it was indeed a more "careful" approach. But I
like your idea doing it more agile. 

> I think that we should use an agile approach to this task:
> - commit it to sandbox (branch trunk, add your components, make 
> configuration changes)
> - "official" review/test from us

This would definitely lower the communication overhead. And lower the
bounds for potential testers: checkout the branch from sandbox, build,
run. It would give us a better overview before going live to trunk.

> - when any "blocker" issue is solved merge it to trunk
> - then I expect we can discuss and refactor it while a working version 
> is in trunk: maybe someone will start short-living branches to show his 
> ideas.

An early merge to trunk will probably give us the most progress. As long
as we are not doing substantial changes to other parts of James and
keeping some kind of wrapper in between I see no risks for future
releases.
Maybe the ideal way would be developing the perfect API first and do the
complete integration in all parts at once.
Being pragmatical I think the API Imap uses, and the API rest of James
uses, will come closer together step by step, until no wrapper is needed
anymore. 

Joachim



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