Sean Chittenden wrote:
What I am curious is what is currently on the queue to
become 2.0.1 and what is blocking that right now?
Some progress reports on 2.1 would also be nice.
There's a few bugs in the bugtracker that need to get fixed in the 2.0
series, but there's no reason to wait for all of them to be fixed in
order
to do a 2.0.1...
I'm dying without IMAP working right... Paul, any luck with that or
hopes that it'll make it into a 2.0.1 release? :) -sc
The fixes provided by Mikhail will go into 2.0.1 if up to me. The are quite effective in improving fetch and
search performance. Same goes for some other minor changes.
All the really big changes connected with glib/gmime and the new headertables will never end up in the 2.0
series. That's 2.2 stuff to be written during the 2.1 cycle.
Imo, we should merge the pending 2.0 patches (Mikhail's and my own), release 2.0.1 next week, and release
2.1.0 at the same time based on the state of cvs-head. The 2.1.x series should of course be marked as strictly
experimental, not for the fainthearted, and definitely not for beginners. I will do my very best to keep 2.1
production quality - given that I use it myself on a fairly busy system, but things *will* break now and than.
Some of my plans for 2.1:
2.1.0: uses glib/gmime for message insertion and imap response construction
2.1.1: replace the internal list implementation with GList
2.1.2: phase-out the internal mime-parser in the message-retrieval chain (this
is a big one).
2.1.3: replace the internal cache system in favor of a more scalable design
(GCache?)
Parallel with this internal design issues, there remains the problem with the shared libs that are not really
shareable atm. A plugin interface would be nice (dlopen), a mechanism for calling external scripts (python,
shell, procmail, perl, whatever) would be radical.
Authentication has to be redone. Either we finish ldap-intergration or we strip out ldap and provide only pam
as an external authentication mechanism. That would be a killer feature in my view.
Same goes for sieve. It should either work, or be removed from the codebase to be replaced with a generic
framework for calling external filters.
I hope neither will be necessary given the amount of work Aaron has put into both, but too much code is
cluttering the source that is never used, largely unmaintained, and making life difficult for people working
on the code or buildsystem.
just my 2ct.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
