[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

URL registerer - proposal for a new Internet Service



During the last dinner, I talked with Ira and Omer about my idea of establishing
a DNS service for URLs, i.e a server program that will retrieve a web page URL by its 
name, just like the DNS retrieves a host IP by its hostname.

For example, if I contact a URL registrer and asks for "Yahoo Homepage" I will get 
"http://www.yahoo.com/". The need for such service derives from the fact that just as hosts 
can change IPs so can web pages change their host and/or path. How many times have you 
seen the message "This page has moved. Its new location is http://blah.blah/blah. Please 
update your bookmarks."? The URL registration service will enable web driectories, search 
engines and basically, every page that has links to other pages, to bypass this mess. The 
creator of the webpage registers it and its current URL in the registrer. Afterwards, 
whenver that page is referenced (whether in a web directory, "Links" section, etc.), it is 
linked through the URL registrer. Then, if he wants to move his page to somewhere else, 
all he has to do is change its URL in the URL registrer, and then all the links will route to 
the new page. 

At the dinner, Ira noted that basically thats what Yahoo is supposed to do in the first place. 
I disagree with him: Yahoo is a web directory which is supposed to categorize pages by 
topics, thus making them easier to find. If I wanted to access Microsoft homepage I knew it 
was http://www.microsoft.com/ without Yahoo's help. But if I'm looking for a site that has a 
database of chemical formulas, I couldn't have just type the first URL that sounds suitable 
enough, or could I? 

But, what if this chemical formulas page was referenced in Yahoo, Excite, WebCrawler, 
InfoSeek, other smaller web directories, various search engines, and in "Hot Links" sections
of chemistry related sites. How will the page maintainer update all of its links, some of which 
were made without notifying him first, if the page moves to a different location?

That's the purpose of the URL registerer. The registering service (I will further refer to it as 
LRS for "Locators Registering Service") will probably have some other functions. Every site 
can have several "children", e.g. "The Linux Documentation Project" is a child of the "Linux 
Project", and it could enumerate them. Or maybe reverse LRS. The LRS server should be 
sufisticated enough to handle aliasing, parent-child relationships, sub-pathing (e.g. the 
Howto's path should be constructed from the Linux Project path + "/FAQs".), passing CGI 
parameters into an LRS resource, etc.

I do not think that it is necessary to have one LRS network. In fact, more than one LRS 
servers, could be present, and the page owner should specify the server hostname in the 
LRS call (like "lrsp://lrs.ibm.net/Linux HowTos"). Several competing LRS providers can 
coexist, as well as public domain or free LRS servers. As long as the LRS server keeps its 
hostname (:-)), everything goes fine.

I can think of three main methods to implement LRS on web pages: server-based, client-
based and "transperent". A server-based implementation means that the server server
sends the web browser a page with normal http:// links. However, it updates the web
pages from time to time based on a template by requering the LRS server to retrieve
the most up to date locations of the desired pages.

A client-based implementation depends on the web browser to do the LRS lookup. The
links on the web pages that the server gives it, contain an LRS url (such as
"lrsp://lrs.ibm.net/Linux HowTos" or "{lrsp:///...}") and the browser needs to connect to the
LRS server, retrieve the page URL and then connects to its HTTP server normally. 

The main advantage of the "transparent" LRS implementation is that it requires no 
special consideration from either the HTTP server or the web client. The man who
registered the page simply receives a different HTTP URL that points to the web
server. After the browser connects to this URL, it gets an HTTP redirection to 
the actual page location. The LRS server need not necessarily be a CGI script
in that case. It can be a standard TCP/IP server that speaks the HTTP protocol,
and resides on a different port than the host's web server (if any).



I'd like to know what you think about LRS and if it is worth bothering. Any
suggestions for programming/publicizing and where should I turn to next
will also be appreciated.

	Shlomi Fish


Follow-Ups: