Ok, this is my first initial thoughts on design and editing of Hypermail. How
to make Hypermail v2.
- We aim at changing the existing source code. This means we don't change
things unless we think we gain functionality or speed. It also means we remain
using C and we do intend to make this portable.
- We need a first developer release to enable people to start working. This
release should have all "good" patches applied. We will need a list of
patches, who made what and stuff like that.
- We need a bug list gathered. I'd prefer keeping the bugs separated from the
requested features since the bugs are likely to be more important to fix, and
in many cases require less efforts. While A and B
The way I see it, Hypermail was designed in a classic manner where classic
mistakes were made. The most obvious one was that every part in the program
are too closely intertwined with each other.
I think Hypermail could be seen as (at least) five different blocks that
cooperate. Each of these could be written and maintained rather separated from
the other parts, only to allow specified interfaces of how to use each other.
These parts are:
- read mail one by one from a selected source and split them up in single
mails
- mbox format file
- stdin
- more?
- convert single mails to HTML
- selectable headers to be included?
- URLs converted to <a href> tags (includes email adresses)
- quote recognition for special formatting
- MIME decode (quoted-printable)
- extract attachments ("inline" gifs, jpegs and HTML files)
- uudecode awareness?
- more?
- keep a list/tree with all mails' headers
- Full RFC822 compliant header parser
- create different indexes
- thread tree
- date sort needs good Date: parsing
- author sorted
- split indexes when too big / date dependent?
("continued" and/or "older" link?)
- more?
- output HTML files
- date oriented / remove too old files
- number of target files (max X files?)
- allow configuration (header, footer, links etc replacable)
I think we'd gain a lot if we could reach a construction like this. We'd gain
ease of modification and extension, we'd get easier to track bugs and the
source would become easier to read.
We might be able to accomplish all modifications without re-arranging a single
source line. If we can do that, we won't restructure anything. Let's not take
on more work than we have to.
--
Daniel Stenberg - Software, Network and Unix
GSM: +46 - 708 - 31 77 42 http://www.fts.frontec.se/~dast
Received on Mon 27 Apr 1998 02:15:45 PM GMT