RE: Transport requirements for DNS-like protocols

[John C Klensin <[e-mail]>]

--On Monday, 01 July, 2002 08:52 +0200 Patrik Fältström
<[e-mail]> wrote:

> --On 2002-06-30 21.14 -0400 John C Klensin <[e-mail]>
> 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