Re: transports directory

[Tom Samplonius <tom@uniserve.com>]

On Thu, 6 Jul 1995 Nicholas_Briggs.PARC@xerox.com wrote:

> Since I haven't upgraded from ZMailer 2.2 to ZMailer 2.99.xx, because of the
> unreliability (see the archives!), I can't say that i'd be real tempted to
> upgrade if you rewrote the scheduler.

  You are forgiven!  _IF_ I re-wrote the scheduler, it would have to stand 
on its own merit.

  My own concern is that Zmailer has advantages over Sendmail, but those 
are rapidly eroding.  However, both Zmailer and Sendmail still don't do 
everything that I want them to do.  Either it develops, or it dies.  It 
concerns me that you are only one to have any thoughts on my proposals.  
Are we the only two on this mailing list?

  Besides the plans for the scheduler, I have even more radical ideas for 
the router to do away with the buggy zmsh code (the archives show that 
router processes tend to core dump even in 2.2; even Rayan states that it 
tends to crash if gets something "unexpected").

> Since i'm acting as a gateway for all of Xerox, Fuji Xerox, and Rank Xerox, I
> don't think there's a timezone that I don't have correspondents in -- so I
> can't afford to run code that crashes periodically, and requires attention when
> I get to work in the morning.

  Testing is serious concern.  I think a big problem is the differnet 
hostenv options.  Most have not been tested throughly, if at all.  For 
example, does the scheduler really work without select()?  I doubt it.  Is 
the mmap vs read/write providing the same results?  It should.

> >  Basically, all that would be eliminated would be the management of the
> > channel directories in scheduler/* (automatic creation and deletion, etc).
> 
> But if this is all you're talking about eliminating, it's got to be such a
> miniscule part of the disk I/O it can't possibly be worth it....   Since I
> *always* have "smtp" messages in the queue (and "hold" messages in the queue),
> the channel directories never come and go.   If a machine is emptying the
> queues, then it should have cycles available to create/delete the directories.
> 
> So what am I missing?

  I agree completely.  It is _small_ part.  My main point, is that is is 
simpler.  If re-write were to be done, a simple design would be 
prefereable.  In the future, when more enhacements are done, it will be 
to integrate.  A few possibilities for the future (that is, after a 
re-write):

  - Pass the message text as well as control information into a transport 
agent.  This would allow the scheduler to do message caching, so that if 
a message required local, smtp, and uucp delivery, it wouldn't need to be 
read from disk three times.


> Keep in mind, also, that you do want to create the files somewhere else, and
> then link them into the directory where the scheduler is going to look at them,
> because you can't afford to have the scheduler start to look at a file that is
> not complete yet.

  I think that this was covered in CS 201!  :)  I think I can manage...


Tom