# Re: Uniform Resource Names - almost draft

Patrik Faltstrom (paf@nada.kth.se)
Sat, 15 Oct 1994 09:27:45 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Martin Hamilton: "Re: Uniform Resource Names - almost draft"
- Previous message: Mitra: "Uniform Resource Names - almost draft"
- Maybe in reply to: Mitra: "Uniform Resource Names - almost draft"
- Next in thread: Patrik Faltstrom: "Re: Uniform Resource Names - almost draft"

    Message-Id: <aac53dd40202100410a3@[130.237.222.107]>

    Date: Sat, 15 Oct 1994 09:27:45 +0100

    To: Martin Hamilton <martin@mrrl.lut.ac.uk>

    From: paf@nada.kth.se (Patrik Faltstrom)

    Subject: Re: Uniform Resource Names - almost draft

At 20.31 94-10-14, Martin Hamilton wrote:
>Patrik Faltstrom writes:
>
>| 1) You are not able to include the actual handle name (the URN) in
>| a centroid, so you will not get all information you want, i.e.
>| no servers-to-ask response.
>
>Won't the URN attributes from the template appear in the centroid ?

Yes, it will, but if you search for a handle, you must give an exact
name of the record itself, i.e. the server will not search and give
you servers-to-ask responses.

>Fair enough ! I suggested it because the handle specifier seems to
>be the only way of bypassing the search mechanism. I was really
>thinking about overloading the handle rather than forcing
>implementors to make URNs the handles of their templates. A URN
>lookup can be detected easily because it always starts with something
>like...
>
> handle="URN:
>
>or
>
> handle=URN\:
>
>But perhaps the URN lookup is so important that it deserves a special
>whois++ specifier of its own ?

I don't think we should try to find all kinds of ways of searching for
am URN without using the normal search algorithm in the whois++ server.
The search for an URN is a search (with exact match) for a textual string
in a special attribute name (URN) in a special template (URN) so the
search can not get any faster than that anyway. You have to implement it
as either a hashed value or a b-tree or something like that anyway.

I do not see any reason for finding a special grammar in the whois++
protocol (yet) for URN searches.

It might be needed in the future, but I can then see lots of other
places in the protocol which we have to look at, for example the
protocol itself and the "client interaction with a whois++ mesh".

Most of the time spent waiting for an answer will be in finding the
correct whois++ server, not a search in an indexed table for the URN.
Even though you have the centroid mechanism, finding a server means
that you do search the "Directory-Of-Servers" for a top-node
server for the actual template you are searching for, or the
describe-tamplates of all servers of the world. After that, you
start to traverse the whois++ tree. So, you do have lots of
interaction with the network before doing the actual search for
the URN here.

>Isn't it a bit dangerous to assume that server implementations will
>deliver search results within the resource/time constraints expected
>of lookups ? For instance, it would be nice if the server could
>handle lookups without forking, a la BIND...

This all depends on how the server is implemented. We can not in the
protocol make constraints or guesses on how a server is implemented.
It might be implemented as a two-step search which first searches
for handles for all records which matches and later it retrieves
the records (my server work like this), but it might also be stored
in a way that the search and retrieve is done in the same operation
inside the server (my server did work like this). I did change the way
it works because I can not have the server tailored for a specific
kind of template, and the slowdown is minimal if (as in my case) the
underlying database is fast.

Patrik

- Next message: Martin Hamilton: "Re: Uniform Resource Names - almost draft"
- Previous message: Mitra: "Uniform Resource Names - almost draft"
- Maybe in reply to: Mitra: "Uniform Resource Names - almost draft"
- Next in thread: Patrik Faltstrom: "Re: Uniform Resource Names - almost draft"