distributed mailing list? (Was Re: [SunRescue] Question...)

[Joshua D. Boyd]

On Fri, 25 May 2001, Dan Debertin wrote:

> Pass DynamicTemplate a reference to a hash (or something like that..) that
> has appropriate values for $user, $time, $day and $thingie, and it will
> tokenize & substitute the vars into the template. Works great. I've used
> it for not only HTML, but also auto-generated emails, LaTeX documents,
> etc., etc.

Yeah, well, one of the main goals of my project is to get rid of perl,
because perl takes more diskspace than a stripped python install (maybe a
stripped perl install takes less.  I'm not that intimately familiar with
perl).  Later, I want to look into trying to get rid of the python install
requirement all together (at least for the Windows version) buy justing
having a shell program that links to python.dll.  I'm not sure how well
this will work out since I'm using wxPython a lot.  It might mean needing
to redo the gui in C, but it is a simple gui, so that isn't a major
impediment.
 
> > Anyway, getting back to the topic of mail servers.  The problem with
> > flat files is that they can be a pain.
> 
> And databases aren't? How many nights have _you_ spent isamchking tables
> and manually fixing a database because somebody did a "UPDATE" without a
> "WHERE" clause, and reverting to backup is not an option?

Never had to do that.  I've always worked in environment where all changes
to the database and tested on a test server first.  Besides, we are
talking about a system where the user shouldn't be fiddling directly w/
the database much.
 
> The difference between databases and flatfiles is that with a database,
> generally when they break, the whole thing breaks. Mail is especially bad
> for this, as it's the first thing users notice. We could drop all of our
> outbound DS3s, randomly kill httpds, power down RADIUS servers, but if
> people can't get their mail, _that_'s when the phones really start to ring
> :/.

Yeah, the whole thing breaking is the downside.
 
>  > Now, if the server ran reiserfs, we could just place each and
> every
> > email as a text file.
> 
> Maildir format does this as well.

Do you happen to know how it overcomes the file system problems with
thousands of little files?

> You've got me there. I think that's why people use it; It effectively
> combines RPC with NFS. I just don't think that's a good enough reason.
 
Yeah, well, even I think that is a good enough reason for testing, proof
of idea, and quick (but hopefully not mission critical) programs to use
SQL where SQL might not be the best choice.

Speaking of RPC and NFS, I've seen a number of NFS servers (refering to
the serving software) that sit in front of a database, allowing you to
access database records as if they were files.  This were mainly for
source code control systems, and programs to allow rolling back the clock
to literally any second (where as with NetApps, you apperently have to
tell it before hand what roll back increments (ie, 1 hour, 1 day, etc,)
will be allowed.)

Of course, if we really wanted to make this project interesting, we would
do it on BeOS, where we can make each file a record (message text in file,
everything else as attributes), and where the file system attributes can
easily be queried.  The file system was always the thing I found most
interesting about BeOS.  I wish I had the spare cash to setup a BeOS
machine as an application server.  Maybe I'll be able to scrape together a
spare system this summer.  I'll put it on the list of things to scrape
together system for.


--
Joshua Boyd