From: Brad Templeton (brad@templetons.com)
Date: Fri Mar 03 2000 - 16:42:15 CST
On Fri, Mar 03, 2000 at 01:00:19PM -0800, Russ Allbery wrote:
> Brad Templeton <brad@templetons.com> writes:
>
> > So what about adding 'em? That does solve all the issues, at a cost of
> > disk space in the history file. Disk space is hardly expensive.
>
> It doesn't just cost disk space; it costs memory. You want as much of the
> history file memory-resident as possible for speed. And memory *is*
> expensive. It's not a huge increase, but you're talking about increasing
> the size of the history file by ~10%, roughly.
Understood. So let the slaves do it. They do cancel, they should do
replaces. Allocate an article number for them if they need it and put
it in the xref. Let them add to it.
Replacement is rare but useful, it is not a burden for the slave systems
to do it.
>
> > But they must do other things, like interpret cancel messages, no? How
> > do they do cancel messages if they don't have a history file mapping
> > msgids to numbers?
>
> They don't. The slaves do. At least in most of the clusters I'm familiar
> with. An increasingly common way of handling cancels is entirely within
> the overview, without any changes to article storage, and the slaves are
> the systems with the overview files.
You misunderstood. I asked, since the slaves have to be able to handle
cancel, they have the data they need to handle replacement.