image provider

WebRing Controller


Disclaimer

This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.

This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.

Please do not email me about this project without reading the disclaimer above.

This project is not so pressing now that the WebRing people are finally getting their act together and making the system user-friendly.

WebRings are groups of like-minded websites. You can browse from site to site in a circle by clicking a button. You can go forward or back. You can jump to a random site. You can see a list of all the sites and jump directly to any one of them. Yahoo organises such rings for free. For details on how they work, see WebRing in the Java glossary.

There is a central controller CGI (Common Gateway Interface) app running on a server that figures out where to jump to next when a given button is pressed. When the user hits next, prev, random or list, (usually on a custom CGI graphic map or a snippet of JavaScript) the server forwards the user to the appropriate site in the circle. There are three major problems with WebRings as they currently exist:

  1. The HTML (Hypertext Markup Language) for linking at each site is not properly verified. The target URL (Uniform Resource Locator) should be precisely the spot on the page where the link control to the next site is, with #NAME tag. With the current unverified schemes, you may land at somebody’s home page and have to dig through his entire site to find the next link. (There might not even be one, if the site’s owner made an HTML error, or dropped out of the ring without informing the Ring Master.) You may land on a page with links to 20 other WebRings on it. You have to find the link for the WebRing you are interested in. We need to automatically verify (and periodically reverify) that the HTML target URL and the link control HTML buttons at that target are properly configured. You need a precise target URL of the form:
    http://www.MySite.com/ringpage.html#SuperRing$209078$7752$13413
    where SuperRing is the ring software scheme, 20978 is the server id, 7752 is the ring id and 13413 is the site id. IDs are small integers evenly divisible by 17 (which acts as a simple checksum, yet allows ids (after division by 17) to directly index tables).
  2. Like the old serial Christmas tree lights, if any link in the chain goes down, the entire ring is broken. The central site needs to keep tabs on all the sites and remove ones (temporarily and eventually permanently) that do not respond. Some rings have a button to bypass the next site to help get around the problem. However, that won’t help unless the user knows to try that. It also requires there not be two dead sites in a row. Note that current schemes don’t directly send the user to the next site in the ring. They always send him to the ring hub for redirection. However, if there is no working link back to the ring hub, the chain is broken.
  3. Users periodically reorganise their websites. This means that rings may move from page to page without officially informing the central site of the new location. These links can be made self-healing. On the other extreme, you could insert a perfectly standard piece of HTML in a web page, not customised in any way. It looks up the web page URL to see what rings are registered there. You could put that link on every web page, then manage centrally at the ring hub which rings you want to appear on which pages. You could have a ring appear more than once on your website. You could see centrally which links are valid. What you want to avoid is the problem of needing to install new gobbledegook nav bar codes every time a web page is renamed or split.
Your job is to write a servlet that runs a collection of WebRings, sending browsers onto the next link. You need to find low-cost, solutions to the above three problems. You want the user interface extremely simple so that almost anyone could set up a WebRing server and run it with little time investment.

There are four levels of organisation:


This page is posted
on the web at:

http://mindprod.com/project/webring.html

Optional Replicator mirror
of mindprod.com
on local hard disk J:

J:\mindprod\project\webring.html
Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

IP:[65.110.21.43]
Your face IP:[34.206.64.143]
You are visitor number