Design Goals of Venice/Dynamo

Eric J. Bowersox, <erbo@silcom.com> - May 2003

Introduction - The Original Venice Goals

As is well-known, the Venice Web Communities System was originally founded for the purpose of providing code on which the new Electric Minds server could be run. To this end, it was designed along the lines of the CommunityWare platform, by Durand Communications, on which Electric Minds was run for several years. (CommunityWare formed the nucleus of the WebbMe portal system as well.) To that end, the original design goals of Venice looked like this:

  1. A replacement for the CommunityWare/WebbMe conferencing system
  2. Java/JSP/servlets implementation running under Apache Tomcat, MySQL backend
  3. Multiple communities hosted per server, each with multiple conferences (and other features); users logged into one server can join multiple communities
  4. Conferencing functionality similar to CW/WebbMe:
  5. Enhancements to existing conference features:
  6. Later, replace other CW/WebbMe functions:
  7. Features from CW/WebbMe we won't do:
  8. Blue sky features:

Evolution of The Original Venice Code

As time went on and the Venice code was put to use on Electric Minds and elsewhere, gradually, the enhanced feature set described in "Enhancements," above, was implemented, as well as some additional enhancements (user photos in posts, some limited customization capabilities). This was in response to the needs of Electric Minds and other communities

Perhaps the biggest change, however, was a changeover from the original UI front end, which used a great many "magic servlets," to a generalized system which employed a scripting engine built into Venice (actually, the Bean Scripting Framework, which supports many different scripting languages), so that UI-level operations could be written as scripts and executed directly by means of a single servlet. The JSP-based display front ends, too, were updated, making heavy use of JSP tag libraries to minimize the amount of embedded code on a page.

A partial XML-RPC API was also implemented, and the "mailgate" program was written to take advantage of this, providing a gateway from a mailing list to a Venice conferencing topic, with some success.

Dynamo - The Next Leap Forward

Currently, the Venice code is being rewritten to be even more modular than before, carrying the advantages of the modularized, scriptable UI into other aspects of the code. As part of this effort, the lower-level support elements of the application are being factored out into a code framework referred to as "Dynamo" (for "DYNAMic Objects"). The goals of the new Dynamo-based Venice are as follows:

  1. Even greater modularity than the original Venice, including dynamically-loadable modules. One should be able to add a new service to Venice simply by dropping a JAR file into a directory on the server and performing an installation process from within Venice's administrative UI.
  2. Replacement of the JSP front-ends, which involve a high degree of overhead as well as the need to employ external access protection to prevent them from being invoked directly by an end-user. Instead, a solution based on the Velocity template system will be employed.
  3. Refactoring of database access, to eventually allow the use of databases other than MySQL, especially ones which employ stored procedures.
  4. Improved search capabilities for posts, possibly employing the Lucene full-text search engine.
  5. Shifting of configuration information from XML configuration files to the database, where it can be modified without bringing down the server. A new "property" storage system will be employed for much of this information.
  6. Replacement of the original Venice security model, which employed a somewhat-confusing system of "security levels." Instead, a more modern ACL-based system will be employed, for greater granularity.
  7. Replacement of the front-page publishing model to allow people other than administrators to "publish" posts there. Instead, a system of "channels" will be created, with each channel having its own ACL to permit other people to access it.