From owner-freebsd-hackers  Mon Sep  1 01:35:21 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA14582
          for hackers-outgoing; Mon, 1 Sep 1997 01:35:21 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA14577
          for <hackers@FreeBSD.ORG>; Mon, 1 Sep 1997 01:35:17 -0700 (PDT)
Received: from gurney.reilly.home (d14.syd2.zeta.org.au [203.26.11.14]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id SAA25620; Mon, 1 Sep 1997 18:14:25 +1000
Received: (from andrew@localhost)
	by gurney.reilly.home (8.8.5/8.8.5) id SAA00583;
	Mon, 1 Sep 1997 18:13:02 +1000 (EST)
From: Andrew Reilly <reilly@zeta.org.au>
Message-Id: <199709010813.SAA00583@gurney.reilly.home>
Date: Mon, 1 Sep 1997 18:13:01 +1000 (EST)
Subject: Re: Netscape Communicator 4.02b7
To: toor@dyson.iquest.net
cc: mike@smith.net.au, benedict@echonyc.com, peter@grendel.IAEhv.nl,
        hackers@FreeBSD.ORG
In-Reply-To: <199709010509.AAA04960@dyson.iquest.net>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Mike Smith said:
>> Communicator forks to create the DNS helper process (a great idea, 
>> IMHO)

I don't know much (anything) about Netscape's DNS helper, but I
assume that it is some sort of DNS cache, to help avoid DNS traffic
of some sort.  Why is it a good idea to have an application-specific
DNS cache, instead of tweaking named?

I guess this rubs something I've been trying to sort out on my system
at home, and finding that it's not at all trivial: there are protocols,
services, and agents in the Internet world.  (Particularly) on dial-up
systems, it's useful to cache a lot of the information provided by
these services:

Mail: run sendmail in DeliveryMode=delayed and flush the queue on linkup
News: run inn with a suck feed
DNS: run a local named
WWW: run a local proxy cache and turn off cacheing in all the clients
(this is the one I haven't sorted out yet...)

Without this sort of arrangement, you end up (well I do, anyway) with
multiple, incompattible browser caches, excessive dial-ins for random
name lookup, and massive code overkill where each application
re-implements these functions.

If I had buckets of time, I'd like to design a "generic Internet cache"
that implemented all of these in one lump that was as easy to configure
as "my service provider has nameservers xx.yy.zz.aa and xx.yy.zz.bb,
domain name foo.com, and news, pop, smtp, and http-proxy hosts of ....

Then all clients could operate in "trivial, fully connected" mode, with
localhost as their only reference point.

Anyone keen?

-- 
Andrew

"The steady state of disks is full."
				-- Ken Thompson