=> What's the *inherent technology* difference between a registration
=> lookup and a general white pages service?
=
=Registration lookup deals with hierarchical namespaces, thus enabling
=delegation of authority.
True for (part of the) IP-Addresses and certainly for Domains.
Not true for (at least) AS numbers and communities (and inet-rtr).
I think the RIPE registry and DB-SW has never made an (explicit or
implicit) assumption about a hierarchical structure of regsitry data.
This was (for the address space and routing) introduced by the
Class-C-Blocks, CIDR and Reg/Local-Registries approach, and the rwhois.
> A general whitepages service deals with flat
>namespaces which are much uglier to deal with, particularly as the
>database scales.
>
>In addition, registration lookups (should) result in a boolean result,
>it is either there or it isn't. A general whitepages service can
>result in multiple hits, requiring additional resolution.
Agreed.
[....]
=> Then I don't understand why we have the recursive lookup for person
=> objects...
=
=Because person objects are indexed (or did I misunderstand the
=question)?
Partly, I think. I understood your reasoning to eventually propose
removal of the person lookup as contacts for the (hierarchical) objects.
Or to include the contacts directly with the objects? Otherwise, if you
want to keep that functionality to find out about contacts, how would
you do it without indexing? I seem to be missing something, maybe an
implementation fact... Or have you been thinking about the *reverse*
lookup?
=> Those of us who have to work with end-users have to process a lot of
=> requests that involve dealing with person objects. Whether they are
=> directly indexed or just referenced doesn't make a big difference.
=
=I understand. As I'm not a complete fanatic (:-)), I wouldn't throw
=out the person name indexing without providing a replacement that
=would allow people to lookup their names (I've been playing around
=with LDAP -- seems OK, particularly given some browsers are now
=appearing with LDAP clients). In the white pages record would be an
=(optional) entry for NIC handle(s).
So what's your proposal? To eventually run a whitepages server
alongside the other software and to gradually move the person
information to that other server and implement the linking by way of
the handles?
Or to rely on a whitepages service provided by third parties?
=> I want to find out whether some guy or gal is already in the DB - full
=> stop. And it's more comfortable to do that with a wildcard replacing a
=> "sharp s" or an umlau than being "radical" and try all the different
=> possibilities that I can imageine.
=
=This is a hard problem. My concern is that if you throw in stuff that
=would allow fuzzy searches, you'll end up making the code more
=complex, slower, and the resulting index files will likely get (much)
=bigger.
As I said at the beginning of this thread, introducing this
functionality would need some major discussion and decision. Whether it
would make the code more complex and slower and increase the size of
the index files is then a question of implementation.
> An alternative solution, already proposed by David (:-))
>would be to mirror the appropriate database files and use grep (or
>more reasonably, given the requirements, glimpse or agrep). While
>somewhat lacking in elegance, it'd probably be faster (given network
>latency).
Well, I never insist on a *specific* implementation, you know :-)
And yes, that approach is already available.
Even with the opportunity for setting up a "realtime" mirror DB.
Whether we expect all the registry staff to use that approach is a
different issue... But as long as nobody else speaks up, I think it's
not a real issue, anyway.
Cheers,
Wilfried.
--------------------------------------------------------------------------
Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at
Computer Center - ACOnet :
Vienna University : Tel: +43 1 4065822 355
Universitaetsstrasse 7 : Fax: +43 1 4065822 170
A-1010 Vienna, Austria, Europe : NIC: WW144
--------------------------------------------------------------------------
