From Newsgroup: news.software.nntp
Nigel Reed <
sysop@endofthelinebbs.com> writes:
When adding a new peer, it's possible they will have groups that none
of your other peers have. I've been trying to think how I can get the
old articles with minimal bother to the peer admin.
What about adding IWANT ?
Something like IWANT [GROUP [<from> <to>]|[last xx articles]]
The peer then can simply mark the server as IWANT friendly with maybe
an optional throttle so they're not sucking up all the bandwidth.
Good idea? bad idea? improvements?
I think thererCOs two related things here:
1) Peers should be able to advertize their desired group patterns via
NNTP, rather than operators having to communicate it out of
band. (This much isnrCOt about backfill, just about the receiving peer
advertizing what group patterns it can accept from the sender.)
This would be easy to address with a new capability.
Concretely the capability might have label ACCEPT-GROUPS, with the
subsequent tokens being RFC3977 s4 wildmat patterns defining which
groups are to be accepted.
Senders are free to ignore this (and existing ones will) but for
those that honor it, it would act as an additional restriction on
what appears the senderrCOs peering configuration.
The group pattern would be taken from news server configuration. ItrCOd
be appropriate for there to be per-server adverts and a global
default (but this is an implementation detail as far as protocol
design goes).
2) Backfill when a new peering is estalished (or re-established after a
gap). While this can be addressed manually with a pull feed, thererCOs
also no reason right now that a sending server canrCOt backfill as far
as it likes, without any prompting from the receiver.
That suggests another new capability, documenting the maximum age of
article theyrCOd like to see in backfill, if the sending server
supports backfilling.
Concretely the capability might be BACKFILL with a single token given
the oldest date that would be accepted, using the date syntax from
RFC3977 s7.1.1.
The expected usage pattern would be:
- for a completely new peering the receiver advertizes a backfill date
based on its own maximum article age.
- for a peering re-established after interruption the receiver
advertizes a backfill date a bit before the last successfull
communication with the receiver.
- a sender may choose to use a backfill date either to rCygo backrCO and
feed older articles that would normally have been skipped, or
alternatively to prune a queued feed (in the case of an
interruption).
This one would require a lot more implementation effort - feeders are
not really designed with backfill in mind.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2