🚀 go-pugleaf

In article <830712929snz@wash.demon.co.uk>
           john@wash.demon.co.uk "John Washington" writes:

> On Sunday, in article <830682895snz@wbriscoe.demon.co.uk>
>      walter@wbriscoe.demon.co.uk "walter briscoe" wrote:
> 
> wb> Renumbering of articles - required where an earlier article is kept and
> wb> a later one deleted currently requires renumbering of those later
> wb> articles.
> 
> It requires renumbering some.  Not necessarily the later ones.
> Your choice.

Good point!  On reflection, I am inclined only to renumber those
articles kept because they are unread although older than the expiry
age.  That minimal re-numbering means that I should be able to tolerate
multiple Snews users and to ignore the presence of DEL files.  I will
aggressively test scenarios to be able to confirm my ideas of the limits
of the work.

[snip]

> You might even want to change the name at the same time,
> e.g. SCNews (Slightly Complicated News).  ;-)

Point taken.  It is appropriate to question.  With good reasons for
inaction, I shall rest.  No major re-design consideration; no
additional features.

[snip]

> wb> I have added a check to deal with snzprune actions.  If the first
> wb> article to be kept is older than the expiry time and a prune action is
> wb> pending for that group, expiry is not done on that group and the user is
> wb> given an explanation and the relevant command. e.g.
> wb>     expire: For alt.msdos.programmers, first do: snzprune altmsdp
> 
> As long as Expire continues not to change article numbers
> I don't see why that would be needed.

Some renumbering is needed, if an unread article is kept, a later one
deleted, and a still later one is kept.

[snip]

> I think an Expire which does little more than the present
> one, but is fast and rock solid, and can be released soon
> is highly desirable and will get an ecstatic reception.
> And I think that's pretty much what you've already done.
> I'm worried you're now trying to gild the lily.

Reiterated point taken.  In an earlier article in the thread, Malcolm
described his introduction of selective deletion of groups by article
age.  I view an article protection mechanism as a logical extension of
that BRILLIANT improvement.  Using the read/unread status as a mechanism
to allow the selective deletion of old articles is a cheap but
functional hack.  It is vulnerable to inadvertent user action with
those wonderful c and X commands.  If there is a demand for proper
selective expiry within a newsgroup, Malcolm will find himself fielding
lots of calls complaining of inadequately protected old messages.  Snews
2 will probably be wonderful.  While between contracts, I would be happy
to contribute to it.  I don't reckon to wait for selective expiry within
a group.  With a new machine, I don't expect to be affected by the major
bug in expire.  Having time and the inclination, I squashed the varmint!

I prefer protecting articles within a group to forwarding to an email
group via mail2snz.  [That John Washington makes good tools!]

I expect to submit the work to Malcolm within the week unless I find a
catastrophic hole I cannot putty within that time.  [See Les Hatton's
Safer C and the Failure of the Tay Bridge].  My best efforts to avoid
the embarrassment of delivering an obvious bug include this public
review, elimination of code complained of by lint at its most stringent
level, covering the code with forcing of all error paths and giving the
code time to allow bugs to appear.  Les Hatton quotes NASA coding error
rates at 4 to 6 per 1000 lines in 1990.  That scares the 5h1t out of me.
--
walter briscoe