Date: Wed, 3 Jul 1996 19:14:17 -0400 (EDT) From: Dmitry Kohmanyuk <dk@dog.farm.org> To: fports@jraynard.demon.co.uk (James Raynard) Cc: ports@freebsd.org Subject: Re: nntpbtr port uploaded Message-ID: <199607032314.TAA08867@dog.farm.org> In-Reply-To: <199607031041.KAA00918@jraynard.demon.co.uk> from James Raynard at "Jul 3, 96 10:41:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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'...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607032314.TAA08867>