Structure of design

From: Daniel Stenberg <Daniel.Stenberg_at_sth.frontec.se_at_hypermail-project.org>
Date: Mon, 27 Apr 1998 14:07:58 +0200
Message-ID: <3544751E.4F4E1DB5_at_sth.frontec.se>


Ok, this is my first initial thoughts on design and editing of Hypermail. How to make Hypermail v2.
  1. 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.
  2. 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.
  3. 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:

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

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT