"Export dbm" program

>   > Also, has there been philosophical discussion about whether the ftp file
>   > is cut (e.g.) once per day, or whether it is linked to the active .db
>   > file?  
> 
> Yes, you were there!  The conclusion I remember was: Cut it once a day
> and provide a trail of the deltas separately with monotonously
> increasing serial numbers.  It was suggested that the serial numbers
> could encode time. 

Interesting!

You're right;  this is the mechanism we spec'd for intra-IRR data exchange
(after we get some cycles to improve on straight ftp).  The biggest
advantage of this "delta" method that I remember was that it conserves
bandwidth ('don't have to ftp the whole file every day) and cpu cycles
(only have to dbupdate the most recent changes:  don't have to do the
whole 3-hour reindex for every large DB every day).

What I was thinking about was the public ftp repository:  the place folks
go to get data is they want to do some analysis (like the PRDB reports 
files).  If this is only updated once per day, then you have an annoying
average-of-twelve-hours-out-of-date problem.  But suppose this file in
the anonymous ftp directory was actually the file that the registry ran
off:  the one that dbupdate updated.  Then whoever got ftp'd this file
for making reports would have absolutely up-to-date information.  (With
the caveat that his info might be so up-to-date that there's a half-finished
record written at the end of the file).

--Dale



-------- Logged at  Tue Dec 13 20:06:13 MET 1994  ---------