WebRing Controller

Disclaimer

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

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.
   • Automatically. At night the central site chases rings looking for broken links. When it finds one, it searches that website for the moved reference. If it can’t find it, it takes the website offline.
   • Semi-Automatically. When you click the icon it could send its location to the central site. If it has changed and if the old page no longer contains the link, the central information could be automatically updated. If the old page is still valid, the central system could generate an email asking for clarification. It might be quite reasonable to have several references to the same ring on a website, though, of course, there has to be one master link where incoming visitors are deposited.
   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.

There are four levels of organisation:

• Individual Site Master

  One for each site on a ring. A site may be on several rings. They may be on rings using different software schemes.

• Ring Master

  Decides the ring’s charter and who should be allowed on the ring. Monitors that members are conforming to the charter. Handles technical support for the sites on the ring. Maintain the master list of sites on the ring and a home page for the ring. Composes a logo for the ring.

• Server Master

  Runs a server than services many rings. Handles technical support from the Ring Masters, but not from individuals or individual Site Masters. Maintains a master list of rings handled by the server and a home page for the server’s ring service.

• Global Directory Master

  Much the way DNS (Domain Name Service) works, the server sites automatically share their directories of rings to form a master directory of rings. This way each site has a copy of the global directory of all rings on the Internet (ideally even including ones not using your software). Alternatively, server sites may not keep a local copy of the complete list, but instead maintain a link to where a global copy can be obtained. End users of the system are, for the most part, unaware of these organisation levels. They can find a list of sites on a ring, a list of other WebRings on the server or a master list of all the WebRings (categorised and keyword searchable) just by clicking buttons.
• You need to use a program like HTML Validator to verify any fragments asked to be included in other people’s pages. It is highly annoying to be given bad html code to be inserted in your web page, even if it works in IE (Internet Explorer). Even though not all browsers support JavaScript, it is probably best to use it to generate complex displays from a tiny piece of embedded HTML.
• To make rings more accessible, even the ringmaster should not need to know HTML. She should be able to generate the necessary embedded HTML master template by answering multiple choice questions.
• The ringmaster should have ways of generating individual or bulk Emails to various subsets of the ring members. Members should have a way of sending emails to the ringmaster. People visiting the sites should be able, using the ring, to send mail to the owner of the site, or to the ringmaster.
• If the ringmaster does not log in for a month, the system automatically polls the existing ring members to assign a new ringmaster.
• The ringmaster should have the option of requesting an automatic email any time someone asks to join the ring or changes their description.
• The ringmaster should be given the power to edit the URLs (Uniform Resource Locators) or site descriptions.
• Since most people can’t edit HTML, think about how you could have a server system that did not require any embedded HTML, just a link to a page or virtual page on the ring server that contained all the rings that site owned. There could be a link back to the site for each ring.
• Become a ringmaster on Yahoo and learn what the practical problems are and the deficiencies with the Yahoo system.
• Site owners are usually both unwilling and incapable of inserting nav bars or ring icons into their HTML. Perhaps this process could be semi-automated. Perhaps the ring master could do it and email the corrected page back for uploading. You want tools so the ringmaster can do this quickly.

standard footer

	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
	Please read the feedback from other visitors, or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission.
	Canadian Mind Products IP:[65.110.21.43] Your face IP:[18.226.166.106]
Feedback	You are visitor number