In the context of WWW applications, a mediator is a service that functions simultaneously as a server on its front end and as a client on its back end, which acts not only as a proxy for the user's request but also performs some useful type of processing on the retrieved document. (I prefer not to use the term proxy since the word "proxy" usually denotes a stand-in that commits to accurately reflect the original, and the mandate of a mediator is specifically to transform the content into something different or enhanced.)
To produce a natural browsing experience, a mediator usually modifies the link URLs in a document so that selecting a link continues to activate the mediator on that link. The overall effect is that a user only has to visit the mediator when first entering a new URL, and from that point on the whole browsing experience is transformed. One way to think of it is that, by setting up a mediator, you've just added an enhancement to every browser on the planet.
To work properly, this functionality involves making decisions about what HTTP headers to forward or change, how to transmit form data transparently, how to manage caching, and how to properly resolve relative URLs in the document. For maximum responsiveness, you also need to parse and process HTML as it streams in and out, which can be quite a complex challenge. (*)
I coined the term when i created Shodouka in early 1995. This might have been the first mediator ever to be created. The interesting thing about mediators is that they allow a server to add functionality to a browser without any effort or software on the client side.
Here are the various mediators that i know of, in chronological order:
This got cited in a nice paper by Adam Rifkin and Rohit Khare.
The last task, of progressively parsing HTML, is especially hard given the awful levels of non-compliant syntax propagated by browsers that blunder their way through garbage without indicating that there are any problems.
Imagine a C compiler that simply guessed what to put in the program whenever it ran into a mistake in your source code -- and didn't tell you anything was wrong. Now imagine several competing C compilers all with different, secret rules for silently guessing what to do, none of which conformed to the widely-known C language standard because they were constantly adding glitzy, poorly-thought-out features to their own dialects of the language and failed to correctly implement the standard itself. To add insult to injury, the makers of this software proudly call themselves "open standards companies" and misrepresent what their products understand -- and generate -- as "standard" anyway.
This is the Web. Thank you, Netscape. Thank you, Microsoft.
| copyright © by Ka-Ping Yee updated Mon 24 Jan 2000 |