From owner-freebsd-ports  Wed Jul  3 16:42:35 1996
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA08832
          for ports-outgoing; Wed, 3 Jul 1996 16:42:35 -0700 (PDT)
Received: from clipper.cs.kiev.ua (cs-demon-64k.cs.kiev.ua [193.124.48.251])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA08615
          for <ports@freebsd.org>; Wed, 3 Jul 1996 16:38:47 -0700 (PDT)
Received: from dog by clipper.cs.kiev.ua with uucp id m0ubbUM-0004wfC; Thu, 4 Jul 96 02:37 WET DST
Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id TAA08867; Wed, 3 Jul 1996 19:14:18 -0400 (EDT)
From: Dmitry Kohmanyuk <dk@dog.farm.org>
Message-Id: <199607032314.TAA08867@dog.farm.org>
Subject: Re: nntpbtr port uploaded
To: fports@jraynard.demon.co.uk (James Raynard)
Date: Wed, 3 Jul 1996 19:14:17 -0400 (EDT)
Cc: ports@freebsd.org
In-Reply-To: <199607031041.KAA00918@jraynard.demon.co.uk> from James Raynard at "Jul 3, 96 10:41:58 am"
Reply-To: dk+@ua.net
X-Class: Fast
X-OS-Of-Choice: FreeBSD 2.2-960501-SNAP
X-NIC-Handle: DK379
X-Mailer: ELM [version 2.4ME+ PL13 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ports@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


[ comments: I screwed To: address in my mail - freebsd-ports@ instead of
  ports@. Apologies. ]

Quoting James Raynard:
> Interesting coincidence. I did a port over the weekend of slurp, which
> sounds very similar. (I haven't committed it yet as the ports
> collection is currently "frozen" until 2.1.5 is released).

hmm, I think that nntpbtr is better program of this class (used both).
btw, how can I get someone committing the port?  ;-)

I would probably cut'n'paste some of my args from my older mail on this 
subject to the end of my mail.

> > - some policy values are in conf.h under WRKSRC.  Specifically, these
> >   are paths to rnews program and history files (choosen to be
> >   compatible with FreeBSD INN port - /usr/local/bin/rnews, 
> >   /usr/local/news/lib/history), as well to directory where nntpbtr creates 
> >   its work file (with list of articles to be retrieved).
> 
> I would make these ${PREFIX}/bin/rnews, etc - there is no requirement
> that ports are installed under /usr/local.

see, this is inside a conf.h, which is source files.  
You can't patch a patch in patches/ easily on-the-fly, can you? ;-)
(of course I can;  the point is just trickery associated).

> >   It is important that this file would be in persistent place (not /tmp).
> >   Now, it is /var/spool/news/nntpbtr-HOSTNAME.  There is only one
> >   file per server.
> 
> ${PREFIX}/share/nntpbr/HOSTNAME is how this is normally done for ports.

nope, this is sort of `run' or `spool' file - it is written by the program
to remember it's checkpoint on restart. (and also flock(2)s it for 
collision detection).

If there would be a separate `tmp' directory for news, I'd probably opt 
for it;  but there isn't any, it seems.

my comments on slurp vs. nntpbtr (basen on experience + program sources/docs):

[...]
I have been seen slurp, and I now the main adavantages of nntpbtr:

- it remembers which articles haven't been tranferred yet, so when 
  restarted, it goes straight to getting them before checking for yet 
  more news;  it also doesn't have a havit to check existance of all new
  articles before retrieving them, so it is quite useful even if your
  link crashes each 20 minutes :-|

- you can kill it and it would save job not yet done for the next time;

- it stacks up to 25 article requests;  i.e., it says server to get many
  articles withouit waiting for each one of them to arrive.  This does
  _great_ savings on high-delay lines (even on dial-up, your typical 
  round-trip time is 150-250ms, so with slurp, you have a delay 2 times
  that after each article retreival.

- it increases size of TCP buffer to ~50K.    Great on high-bandwidth lines

- memory usage is constant and small (~400K RSS)

- blocks on running itself several times at the same time.

the disadvantage is you cannot do group negation like slurp, i.e.,
get comp.os.* but comp.os.ms-windows.* ;-)   oops...  Hurray! You can with INN! 
just use `comp.os.*,!comp.os.ms-windows.*' as your group pattern!
you can even do something like `!*.advocacy'...