Re: Adding something like IWANT to innd?

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 there’s 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 isn’t 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 sender’s peering configuration.

   The group pattern would be taken from news server configuration. It’d
   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, there’s
   also no reason right now that a sending server can’t backfill as far
   as it likes, without any prompting from the receiver.

   That suggests another new capability, documenting the maximum age of
   article they’d 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 ‘go back’ 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/