james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject Re: Imap contribution (Was: IMAP development)
Date Fri, 06 Oct 2006 16:54:12 GMT
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
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


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

View raw message