Mikhail Ramendik wrote:
Paul J Stevens wrote:
Note: the code is hard to read and I could find no documentation on the
database, so I may be wrong here. If so please correct me...
hard to read... understatement at large. That code is a total bitch. A
messy heap of shit which makes
overcooked spagetti look like soldiers on parade. I actually read that
code. Not once, but many times. No
kidding, and not funny so stop laughing.
My grand idea would be to rewrite it - in Python. Python has a g-r-e-a-t
MIME parser sitting right in the standard libraries. And as for CPU
usage, just shift everything we can to the SQL engine.
Yeah. email.py indeed is very nice to work with.
Forward compatibility. I did commit a patch to cvs-head to start using
this field for message insertions, and
have posted a bash/awk script that will fill this field for existing
messageblk rows.
Posted where?
http://mailman.fastxs.net/pipermail/dbmail-dev/2004-September/004678.html
P.S. To be very honest, I did not like the coding style in dbmail. The C
language for this task would not be my choice, but never mind that.
Functions that are hundreds of lines long, with only minimal comments,
are much more problematic.
The original author was probably a very smart guy :-) but a not so
very experienced programmer.
Agreed. I actually recognized the coding style - I wrote that way in
high school. (Only in Pascal, so it was a little bit more readable).
But not much more, I presume :)
I actually volunteered to work on that code last summer :-/ and I've
already begun splitting up some of those
functions. The recent addition of struct ImapSession in
dbmail-imapsession.c is phase one of that refactoring.
The next phase (splitting up and cleaning _ic_fetch) is well underway
and currently being tested. Still much
remains to be fixed, simplified, cleaned-up, etc, etc.
Well, I'm not so sure this can work, but then I might simply be
frightened by the current code. And influenced by Eric Raymond - "Plan
to throw one away, you will, anyhow".
Well, working on that code gave me a certain degree of confidence working in c which is a good thing for any
IT drone. So I won't mind even if we do go for a rewrite.
Besides, by Real Grand Idea would be to use dbmail for local storage,
ultimately building a direct interface to it into at least one mail
reading program. (It's not as crazy as it sounds, when one has nearly a
gigabyte of mail lying around - like I do.)
Well, the idea is to provide a little bit more than just local storage.
And that would require a *clean* separation of functions, just Not
Present in existing code. For example, my idea would involve a search
and a fetch defined as functions, and separate IMAP parsing functions
calling them.
Makes sense to me.
This may be THE critical question. If Ilja goes on with this code, then
it's worth refactoring (especially since a rewrite might mean losing
that).
Perhaps even Ilja won't have any regrets if he can dump the current codebase. However, his input, and Aaron's
as well, is critical in such a decision. And I also don't want to alienate the current userbase.
Should I find myself alone in actually working on the current codebase
I will re-evaluate dbmail's viability,
and may indeed decide to either go for a complete rewrite in python or
move on to other projects.
If you go for Python, you're not alone.
:)
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
