2 - Design Features in WebLinker
The user requirements on WebLinker made several constraints upon the technology options available for WebLinker.
Any Web-wandering robot released upon the Web can create huge network problems by bombarding a site with lots of requests. Thus it was required that WebLinker satisfy the Robot Exclusion Principle.
An additional user requirement for WebLinker was that it should be easy to install for the end-user, and not require a lot of technical knowledge.Thus we opted for Perl version 4 as the language in which WebLinker was written. Furthermore, infostructures using WebLinker can be browsed using current clients. WebLinker requires minimal customisation on the server it resides upon (See Section 3.3).
Another user requirement was that an infostructure passed through WebLinker should be identical to the original one produced by the converter. Unfortunately, with current browsers, this is not possible. The problem occurs when we try to link to a URL with a fragment identifier in it. Fragment identifiers are used by the browser to signal where in a HTML document the user wishes to jump to. The server is never aware of them. This is a problem, since there is no existing mechanism for a server to return a fragment identifier to the client. As an example take the mapping rule below for the FARMING infostructure:
Pastimes farming_33.html#PASTIMESThe LRN for this is http://www.agri.org/lrn/FARMING/Pastimes. The client does not know it is referring to a fragment identifier in an infostructure: it sees this as a normal file. The server returns the document:
http://www.agri.org/farm/farming_33.htmlThe client has no way of knowing that the actual link goes to the fragment identifier PASTIMES in that file.
The solution to this is to return it as a HTTP Header to the client, for example:
Frag-Id: PASTIMESbut this is not supported by current clients and requires a patch for them to do so.
Generated with WebMaker