Path: utzoo!mnetor!uunet!munnari!vuwcomp!duncan
From: duncan@comp.vuw.ac.nz (Duncan McEwan)
Newsgroups: news.admin
Subject: Re: Map expiration dates
Message-ID: <13265@comp.vuw.ac.nz>
Date: 5 Feb 88 00:16:57 GMT
References: <7815@rutgers.rutgers.edu> <13226@comp.vuw.ac.nz> <2056@swlabs.UUCP>
Reply-To: duncan@comp.vuw.ac.nz (Duncan McEwan)
Organization: Comp Sci, Victoria Univ, Wellington, New Zealand
Lines: 76
Summary: If reposting unmodified map files is absolutely necessary, at least
	 do it less frequently than every 30 days!

In article <2056@swlabs.UUCP> jack@swlabs.UUCP (Jack Bonn) writes [in
response to my article about eliminating the periodic reposts of unmodified
map articles]

>It also allows a site to miss a map posting and eventually get an up
>to date map (even if they miss an occasional repost).  Why not increase
>the 30 day reposting to a larger number (say 90 days), until the
>number of maps reposted is reduced to almost none.  This would be ...

I don't think it is much of an advantage if it is going to take a site 3 months
or more before they get a full map again :-).  I think it would be far better
to incorporate some mechanism for allowing a sys admin to figure out that they
had missed a map part, and having facilities available for them to obtain the
missing part.

At the moment it is not easy to tell if you are missing something.  In my
original posting, I suggested putting some kind of sequence number in the map
posting's subject line, which would help [I have seen no feedback about this
suggestion -- am I the only one that thinks this simple change could be useful
:-)]

An idea that I didn't include (the article was already too long :-) was to have
a periodic posting of a shell script by the map maintainer that would compare
the id's of map articles that had been posted with what the receiving site had,
and report to the admin the id's of anything that was missing.

>... because, in the normal order of things, almost all (all?) the maps have 
>a "refresh time" of less than 90 days.

I suggested having no repost, and "infinite" expiry dates because I wasn't sure
what proportion of map files actually got updated over any given period.

But if it is the case that almost all map files are modified over (say) a 90
day period, then having a repost of all unmodified files after that period
would be fine.  We would still have reduced map posting volume to about one
third of the old "once per month full repost" while gaining the advantages the
new fast update turnaround time.

Some feedback from someone in the UUCP mapping project, who actually knows how
long it takes before "almost all" map files have been updated would be helpful.

>I was under the impression that map entries would have an expiration
>date such that a map for a given region would ALWAYS be in the news SPOOL 
>directory.

Well, it should be, given the current 30 day reposting.  I think Mel puts a 45
day expiration date on articles that get posted, which means if you receive
either an update, or the periodic repost, the file will always be present.
However, if for some reason you miss one, and that file is not updated again
soon enough, your news map directory will be missing part of the map (for a
little while at least).

For this reason, I think infinite expiry dates would still be useful, even if
a periodic reposting of unmodified articles is carried out.

>
> [Script to generate map via pathalias directly from news spool directory
> deleted]
>
>By running a script like this (from cron) I don't have to keep two copies 
>of the map data around,

I actually keep one and a half, since the one used to generate the map is
compressed.  The reason for keeping the other copy is because it is required
by John Quarterman's "uuhosts" shell script (automates unbatching, and also
provides a map lookup facility).

But thinking about it, now that the map is not being posted in a small number
of large articles, the unbatching facility of uuhosts may not be required, and
it's lookup facility could be modified to work directly from the news map
directory.  (Or maybe it doesn't even need modifying, since it already has to
skip leading and trailing garbage before displaying the map entry you want).

Duncan

Domain: duncan@comp.vuw.ac.nz		Path: ...!uunet!vuwcomp!duncan