RE: some replies aren't really replies

On Mon, 17 May 1999, Peter C. McCluskey wrote:

> (I'd integrate Critmail with a recent version of Hypermail if I were
> pretty sure that the result would get into the main Hypermail
> distribution, but I suspect that by the time I finished, Hypermail would
> have changed enough that it would still take some effort).

Hi Peter

As one of the guys doing work on hypermail I feel obliged to comment your offer to extend hypermail's capabilities.

To write code for hypermail that is likely to work in a future version too (i.e if you start on something now that you wanna send us after many months have passed) I'd advice you to:

1. Write all your new main functionality in new source files. Limit the interface with a strict set of input and output. Preferably your functions could be tested and debugged stand-alone (this actually goes for all functionality in hypermail) with some compiler flag set.
2. Send us patches at an early state that adds the entry calls to your functions. They could very well be conditional like #ifdef WHEN_MY_STUF_WORK. If we have that already in the code, it is easier to adjust it if we decide to change those parts of the code.
3. Rely on basic principles of hypermail, not specific implementation details. What I mean with this may of course be a bit problematic to grasp if you're very familiar with the code, but if you're unsure of if you can use certain structs etc, you're free to mail us. All us authors are on this list!
4. If the feature is cpu intensive or otherwise likely to be wanted to get shut off at times, make it configurable!

We do need help. We appriciate help. We are dependent on help!

-- 
             Daniel Stenberg - http://www.fts.frontec.se/~dast
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol