
Mishawaka software architecture
---------------------------------

Because Mishawaka is a daemon which will run all the time, it
had to be small and efficient (and bug-free).  Thus, MFC 
(Microsoft Foundation Classes) was not used.

Mishawaka is divided into several source files:

mishawaka.c - user interface (except status bar, list populating, envelope edit)
inbound.c - SMTP receive
outbound.c - SMTP send
pop3.c - POP3 server
schedule.c - mail delivery scheduling, populating list window
dns.c - DNS lookup
status.c - status bar at bottom of window
match.c - generic string matching routines
registry.c - registry read and write routines
timer.c - update text for sending progress
debug.c - the debug window

Before understanding this program one should be
fairly familiar with the appropriate standards. They
are published by the IETF (Internet Engineering
Task Force) as RFCs (Request For Comments).  A
crucial understanding is the difference between
mail headers and SMTP (envelope) information.  They
don't have to be the same, which is why you receive
mail which was "To:" someone else.

The database is a single file which contains envelope
structures.  Envelopes contain all the information
of a SMTP session except for the data.  The bodies of the
letters are kept in separate *.822 files.  The envelope struct
is defined in schedule.h.

Mishawaka is a multithreaded application.  Only one
thread services the user interface.  This one should
not be blocked for long thus it can never wait
on a network connection.  The thread is also the only one
which can write to the envelope file.  Additional
threads are spawned to answer network connections.  These
threads change the envelope database by sending 
application specific events to the main window.  The
interface thread then changes the file, quickly.

Global configuration strings are dynamically allocated.
To make them handles (which improves memory manageability)
would increase code complexity too much for little benefit.

To keep memory growth to a minimum, and because the
daemon spends most of its life idle, and to minimize
corruption on power failure, mishawaka works off the 
disk copy of the envelope file instead of loading it
into RAM.  We rely on Disk Caching to make all the
speed ups possible, and to do it most efficiently
with respect to other processes.

It was very tempting to go mucking with device drivers
for the DNS address, or make the daemon show up as a 
control panel, but I decided to stick to the Win32 interface
for maximum portability.



























