Transparently allowing multimedia and advanced content on existing web based discussion systems

Giovanni Tummarello
University of Ancona
Via Monte d'Ago
Ancona Italy
Christian Morbidoni
University of Ancona
Via Monte d'Ago
Ancona Italy
Francesco Piazza
University of Ancona
Via Monte d'Ago
Ancona Italy


Most of the web applications used today include discussion systems (forums, guestbooks etc.) supporting textual messages. Although advanced functionalities like including diagrams, formulas, tables, images or sounds into messages are a fundamental features in many discussion typologies, very few of the existing "off the shelf" systems support them. We propose a generalized procedure based on client side programming that will take advantage of mostly any existing discussion system enabling the use of such enhancements without changing anything in the software or in the underlying database. The resulting system poses no additional security threat and works on any modern generation browser.


Java, JavaScript, liveConnect, Attachments, Reuse, Binary encoding


Most of the web applications used today include discussion systems (forums, guestbooks etc.) supporting textual messages. Although important for many discussion topics, the support for advanced functionalities like diagrams, formulas, tables, images or sounds is usually non existing due to factors like programming, managing complexity and  security concerns. Sometimes, even if these advanced features would be desirable and an alternative is available, the "legacy" WDS in current use is considered stable and changing it to a new one is not appealing.  We propose a generalized procedure based on client side programming (JavaScript and Applets) that will take advantage of mostly any existing discussion system enabling the use of such enhancements without changing anything in the software or in the underlying database. The system uses embeddings and client side parsing, thus resembling the way generic content is stored and handled on the newsgroups. Crucial point driving this project have been the ease of installation on top of existing systems and the transparency for the end user.


2.1 Data over "formatted" text channels

Enhancing communications over textual channel has been done for decades, main examples being newsgroups and email, but the techniques involved rely both on rich client software and a communication mean whose specifications are well known in advance (e.g 7 bits, 75 characters per line [1]) . The proposed system is, in this sense, more daring as a generic WDS only cares about the human readability of the rendered page. A few examples of common modification to the text performed automatically include  long lines or word wrapping, html stripping, special character html escaping,  long message splitting or truncation etc. These "liberal" handling of data requires a system capable reconstruct the original data stream which is, in turn, some suitably text encoded binary

2.2 Enhancing existing systems

Main feature of the proposed system is the ability of being installed "on top" of existing WDS and with little or no modification to the server side code. We will see in section 3 that the only requirement for this to run is the addition of a single line of JavaScript code in every output page. There are several ways to do this even without modifying the scripting code, for example using web server directives or html frames.

2.3 User requirements

The only requirement for the system to work is the use of browsers with working standard client side scripting (JavaScript) and a Java virtual machine. Obviously, usage of the WDS with more primitive browsers is still possible although the enhanced content will appear in its raw form. While developing the prototype we tested it with the latest version of IE (6.0) and Netscape (7.0).    


3.1 Design alternatives

To enhance existing WDS as we propose, different designs were considered. A "proxy" model would include a third party parsing the site and inserting enhanced objects instead of simple text in the right place, where these are then practically stored in a database on the same (proxy) machine. While this would offer advantages under certain conditions, the request for an extra piece of software or an extra "proxy" machine would have made this an unfeasible solution in many situations.. An alternative approach (which we decided to follow) shifts almost all the processing to the client side, leaving very little to do to on the server side if not to include a JavaScript call inside the WDS html code. This approach is nevertheless transparent to the user, assuming a modern generation browser, including a Java VM,  is used.

3.2 Design details

JavaScript has the ability to investigate and modify the loaded page, including dynamically adding applets. The system we propose has 3 main functional parts, 2 in JavaScript and 1 main Applet:

JavaScript for viewing: will analyze the page [2], recognize data encoded in our format , remove it from the page and pass it to the Java Viewer invoked in the place of the data itself. To recognize the encoded data and set the applet to a correct size (e.g. the size of the encoded image), it will read from the "external header".

JavaScript  for editing: Once a editable text space has been detected (TEXTAREA tag) , it add a "Enhanced Message" button close to it, this being able to invoke the Edit Applet

Main applet: will receive data from the JavaScript for viewing as a Java  initialization parameter and pass it to the appropriated handler. The same object, if called via the "edit" button invoked by the JavaScript for editing will provide a list of installed plug-ins and inject the encoded object into the edit object using the liveConnect technology (or a simple providing the encoded version to be "copy/pasted" in the text area).  

Several components interact in this system, starting with the lower levels:

Internal Header Parser: will invoke the appropriate content plugin  

Adaptors: To remedy the "corruption" of the data as described in 2.1 a cascade of plug-ins (called "adaptors" each handling a specific type of modification) is called. This is very important in "view" mode but the adaptor base class also provides methods to be applied in "edit" mode since a special "escaping" might be the best solution in certain cases. At the end of the Adaptors cascade a CRC ensures that the procedure succeed.

Encoders: On top of "text encoding" plugin provides the best supported text encoding method (Examples are BASE64 [3] or more advanced formats as long as the compatibility has been detected or declared), or give the forum administrator the possibility to choose a specific encode type.

Compactor: It will apply a standard entropy compression to reduce the amount of data encoded.

Content plug-in: it will act either as a viewer or as an "editor" (in most of the cases it will just allow the user to select a local file to include). The system come out with the definition of a java interface, implementing this interface a programmer may easly create a new plug-in.

The scheme for this dataflow is sketched in the below figure:

Figure 1, a schematic of the proposed system


As the system does not require existing software modification, it will cause no security hazard to the hosting server. On the client side, the software will run in a VM sandbox or will provide a valid signature trustable by the user


The original drive for this project was to create a platform for a wide user base to test and benefit from the latest advances in low bitrate encodings. There exists in fact a wealth of very low BPS voice and image codecs but most of these never get to be used by the general public. The proposed framework could allow these formats to be used widely on different devices with the sole cost (for the technology provider) of a port to Java.  Similarly, it is straightforward to image the benefits of specific visualization  plug-ins to discussion groups dealing with subjects as musical scores, mathematic formulas, chess , electronic schemes, UML diagrams,  etc.  Last but not least, a "security" plug-in could users to read/write posts using cryptographical filters.


Works are currently in progress. While the preliminary proof of concept software has been developed and performs correctly, the actual core system and a few primary plugins are currently under active developed and should be available at the time of this poster release at the project homepage:

Plugins under development include image, sound, generic file attachment and a chessboard. Plugins api will also be available for anyone interested.


Software reuse is one of the most cited but yet betrayed principles of software engineering [3]. In fact, in 10 years of web programming we have witnessed hundreds if not thousands of rewritings of WDS. We believe that, as client side technologies are more and more mature, the proposed approach offers an inexpensive and simple way to provide additional features that would otherwise require yet more rewritings.


  1. RFC 2822, Internet Message Format
  2. Document Object Model
  3. RFC 2045 Multipurpose Internet Mail Extensions
  4. Richard Gabriel, November 6, 2002 opening remarks "Objects have failed",