From kfm-devel  Sun Dec 10 21:18:45 2006
From: Rigo Wenning <rigo () w3 ! org>
Date: Sun, 10 Dec 2006 21:18:45 +0000
To: kfm-devel
Subject: Re: Interesting thing with DNS requests
Message-Id: <200612102218.46058.rigo () w3 ! org>
X-MARC-Message: https://marc.info/?l=kfm-devel&m=116578555006825
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart12149089.YK4qPjAvXb"

--nextPart12149089.YK4qPjAvXb
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,=20
On Friday 08 December 2006 10:20, Stephan Kulow wrote:
> What is so problematic about implementing a DNS cache within KDE
> if it turns out to be a problem for soo many people setting up one
> correctly?

Here, I support Thaigo.=20
It doesn't make too much sense to me to replicate the nscd functionality=20
within KDE. If IPv6 is turned off, KIO had not more roundtrips than=20
=46irefox.=20
The issue is how to improve the DNS behavior with something else than=20
caching. Thaigo said remembering last DNS requested would be ok and I=20
would support that. We use round-robin DNS for load balancing and=20
having one user being tied to one server would not be an issue. Fixing=20
the IPv6 issue might help even more.

I think this issue needs serious discussions and not a quick hack if KDE=20
wants to maintain its excellent positioning in the mobile web race.=20
Caching depends on a fast client machines. This is typically not the=20
case for mobile devices. nscd would not work in that context. A one=20
entry remember function would. But there might be other, better=20
solutions. My main aim is that you do not stop discussing the issue=20
only because there is nscd and IPv6=3Dfalse and it would solve it this=20
time. =20

Best,=20

Rigo


--nextPart12149089.YK4qPjAvXb
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBFfHm2CRlGO2Cxp/0RAnweAKCPNdz8MFWGJ5YuiA/xSBtThtZY9QCfciuw
aVbHMxTg3OG+H925FO6ADRQ=
=DVjF
-----END PGP SIGNATURE-----

--nextPart12149089.YK4qPjAvXb--