Re: LDAP shall speak unto LDAP + first cut at best-first searching
Tim Howes <tim@terminator.rs.itd.umich.edu> Mon, 29 November 1993 18:23 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01849;
29 Nov 93 13:23 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01845;
29 Nov 93 13:23 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa16265;
29 Nov 93 13:23 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.05097-0@haig.cs.ucl.ac.uk>; Mon, 29 Nov 1993 16:00:54 +0000
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk
with Internet SMTP id <g.08951-0@bells.cs.ucl.ac.uk>;
Mon, 29 Nov 1993 16:00:34 +0000
Received: from vertigo.rs.itd.umich.edu
by terminator.rs.itd.umich.edu (8.6.4/2.2) with SMTP id KAA25286;
Mon, 29 Nov 1993 10:59:07 -0500
Message-Id: <199311291559.KAA25286@terminator.rs.itd.umich.edu>
To: Simon E Spero <ses@tipper.oit.unc.edu>
cc: ldap@umich.edu, osi-ds@cs.ucl.ac.uk
Subject: Re: LDAP shall speak unto LDAP + first cut at best-first searching
In-reply-to: Your message of "Sat,
27 Nov 93 17:58:59 EST." <9311272258.AA01189@tipper.oit.unc.edu>
Date: Mon, 29 Nov 93 10:59:06 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>
> From: Simon E Spero <ses@tipper.oit.unc.edu> > To: ldap@umich.edu, osi-ds@cs.ucl.ac.uk > Now that I have the protocol layer I've been working on a general > search harness I can plug various strategies into. As I've been > filling in the blanks, I've come upon what seems to be a nice search > strategy based on best first search for solving the soft pages problem > (name->url mapping). Given a few assumptions it should return > near-optimal results. I'm still a bit fuzzy as to how long the search > will take, especially when the object being searched for does not exist. > There may a slight problem in the handling of servers which poll themselves > which I can't quite spot at the moment. I need more sleep. Hi Simon. I'm still a little fuzzy on what it is you're doing and how it relates to your proposed LDAP extensions. If you could take a step or two back and give me the big picture it would be good. In the meantime... You have proposed two kinds of changes to LDAP. One is to handle CLDAP requests better. The other is to support the centroid stuff. The former change is the grouping of requests in a single message, which allows one to send a bind-search-unbind request, i.e. it enables authentication with CLDAP. Is an explicit group-of-messages construct really needed, or can messages just be grouped together in a single udp packet and have the same effect achieved? The latter changes are a little more confusing. In a previous message, you said the new "topology" scope and the namedHierarchy and hierarchyName components were related to centroids. Is the idea that if you look at normal LDAP (X.500) it (usually) has a single "topology", that being a geographical/organizational relationship amongst the servers. By adding these new components, you are allowing a server to live in other topological arrangements, and allowing the client to specify which topology it wants to search? So, for example, you are saying there might be a geographical topology, an organizational topology, a computer professional topology, a general special interest topology, etc. About the algorithm in your last message. It makes sense to me, except I'm not sure what the cost information is for exactly. Is it strictly to be used by the server, or can the client make use of it? If it's the client too, how does knowing what the cost of accessing an item is to the server help the client? -- Tim
- LDAP shall speak unto LDAP + first cut at best-fi… Simon E Spero
- Re: LDAP shall speak unto LDAP + first cut at bes… Tim Howes
- Re: LDAP shall speak unto LDAP + first cut at bes… Simon E Spero
- Re: LDAP shall speak unto LDAP + first cut at bes… Tim Howes