Dan Weber wrote:
On Wed, Sep 29, 2004 at 04:24:38PM +0200, Paul J Stevens wrote:
Agreed. And that's what I'm working on already. However, doing so would be
a lot easier if we implement some kind of test-frame.
Its not a solution, tho it may help.
I think you misunderstand. Simplification of the code is primary. Doing so
requires getting rid of large parts of the code. I'm currently removing all list
code (he leif) and replace it with glist where necessary. I'm also removing all
cache code, and I'm replacing all mimeparsing with gmime. However, since I'm
learning about gmime and glib as I go along, it's much easier to develop all
this new code in a stand alone situation where I don't have to fireup the
daemons sprinkled with trace and sleep calls, connect a gdb to the sleeping
process, set breakpoints, etc....
The reason I'm removing the cache code is because it's an optimization hack
that's totally intertwined with the imap code, making that code unreadable at
best. Also, I'm convinced that cleaning up the code will allow us to focus more
clearly on the important bottlenecks. If a memory cache of some sort is required
it should be reimplemented *after* the cleanup, and fully integrated in the new
message retrieval api in a totally opaque manner.
A real solution as I said earlier is
to simplify processes, enhance function calls, and probably remove hand
crafted parsers for ones which are created by bison. This would really help
because then there is always a maintainable interface to the parser and bison
generally tries to optimize to efficiency.
Well, bison seems a bit of overkill to me at the moment. Though I would agree
with the maintainability argument, I suspect the command parser is not much of a
performance bottleneck in the current implementation. That may change of course
as we move along with the cleanup.
Create a new Makefile.am in the subdir, and make sure there is a reference
in subdirs under the root sourcedir Makefile.am
Hmm, I did try that. Guess I'll have to read more of the info docs than.
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
