Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!van-bc!sl
From: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Newsgroups: comp.mail.uucp
Subject: Re: Making /usr/lib/uucp/paths a _binary_ database
Keywords: pathalias UUCP smail
Message-ID: <2136@van-bc.UUCP>
Date: 10 Jan 89 21:28:25 GMT
References: <486@fallst.UUCP> <490@gonzo.UUCP> <307@twwells.uucp> <2126@van-bc.UUCP> <208@tiamat.FSC.COM>
Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Organization: Wimsey Associates, Vancouver, BC.
Lines: 33

In article <208@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes:
>In article <2126@van-bc.UUCP>, sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes:
>> 
>> This method is quite suitable for a small site with limited disk resources
>> that doesn't forward a great quantity of mail.
>
>Yes, it does satisfy those conditions, but
>IMHO, would it not be easier for a small site as described above to use a
>paths file that has only neighbor links, and a "smart-host" entry to your
>nearest friendly "bigger" machine, who can do the full path look-up for you.
>Granted, you may not always get the "best" path this way, but your mail
>should get delivered, and you should be able to keep your paths file small.

I agree totally. But in some cases a smaller site might want to do their own
thing and be able to route. If you arn't passing a large amount of mail (ie
say less than 100 messages per day) and the system is not otherwise fully
loaded the tradeoff off cpu cycles for disk space is very valid one.

Extending your arguement would mean that only a few large central sites like
uunet would need to run full pathalias files. But that would run them into
the ground trying to do everybody's routing.

My point was and is that this is a simply hack that maintains a simple ascii
database, but is much smaller than the original; and allows a system
administrator to save 300 to 500 kb of disk space by consuming some cpu
cycles.

It isn't for everyone; I don't do it here, I have enough disk storage and a
distinct lack of cpu cycles on my poor little 68010.


-- 
Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532