RE: Transport requirements for DNS-like protocols
John C Klensin <klensin@jck.com> Mon, 01 July 2002 11:48 UTC
Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYK00804JHC8H@eListX.com> (original mail from klensin@jck.com); Mon, 01 Jul 2002 07:48:49 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYK00801JHC8F@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Mon, 01 Jul 2002 07:48:48 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYK00801JHC8E@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Mon, 01 Jul 2002 07:48:48 -0400 (EDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYK0063WJHBDL@eListX.com> for ietf-irnss@lists.elistx.com; Mon, 01 Jul 2002 07:48:48 -0400 (EDT)
Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17OzfH-000PM2-00; Mon, 01 Jul 2002 11:48:19 +0000
Date: Mon, 01 Jul 2002 07:47:49 -0400
From: John C Klensin <klensin@jck.com>
Subject: RE: Transport requirements for DNS-like protocols
In-reply-to: <27312065.1025513558@localhost>
To: Patrik Fältström <paf@cisco.com>, Nicolas Popp <nico@realnames.com>, 'Michael Mealling' <michael@neonym.net>
Cc: Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Message-id: <49106200.1025509669@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0a3 (Win32)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
Content-disposition: inline
References: <17823168.1025345475@localhost> <2626548.1025471624@KLENSIN-TP> <27312065.1025513558@localhost>
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss/>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>
--On Monday, 01 July, 2002 08:52 +0200 Patrik Fältström <paf@cisco.com> wrote: > --On 2002-06-30 21.14 -0400 John C Klensin <klensin@jck.com> > wrote: > >> Sonex/ soundex matches are fuzzy matching, but they are not >> fuzzy search; I think that fuzzy search is going to be needed >> here. > > True. > > I think the reason why I am arguing so strongly for client-side > calculations is just because too many people doing services > forget we have a CPU in the client aswell as the server side. > Just look at the "paged result sets" in IMAP and LDAP which I > still for my life don't understand how people can deploy. It > will cost soo much. "We need it because we have so limited > amount of memory and CPU in the client." is what I have heard. I think that argument is largely bogus for desktop-class machines(see below). It may become relevant for kiosk-like setups and, perhaps, for devices similar to mobile phones and PDAs. But, even then, I'd like to see more split-client approaches, in which a service machine does the retrievals and sorting and selection and keeps state (and pages out information) to the end-system clients. > So, instead of having the client do a search+fetch from the > server, the client also want to pass enough information to get > the items sorted correctly (whatever that can be) + the server > is to keep a state for the client, like a cached view. > > This imply not only that we need semantics and syntax which > enables the client to pass sorting algorithm input to the > server, but also that the server need to keep state. One for > each client. What is the timeout? What happens if new records > are added or removed to the view the client looks at? > > _Extremely_ complicated. Yes. But needed in some cases, although fewer, I think, than is usually assumed by the people who keep proposing these things. It would be, IMO, very useful to develop some coherent model or set of advisory rules for telling the difference. > So, of course one need cooperation between client and server, > where the various calculations are made where it "makes > sense". My point is that "makes sense" is not always the > server. Much more seldom than what people in general(!) think. I think we are in complete agreement. And, in this particular case, I think we are likely to need a more complex search than something that yields easily to client-side canonicalization and lookup, but I see almost no advantage to getting involved with per-client (or per-user) server state. john
- Re: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Dave Crocker
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols Dave Crocker
- RE: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Rob Austein
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- RE: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols Nicolas Popp
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Transport requirements for DNS-like protocols Rob Austein
- RE: Transport requirements for DNS-like protocols Patrik Fältström
- RE: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols Patrik Fältström