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:
- A replacement for the CommunityWare/WebbMe conferencing system
- Java/JSP/servlets implementation running under Apache Tomcat, MySQL backend
- Multiple communities hosted per server, each with multiple conferences
(and other features); users logged into one server can join multiple communities
- Conferencing functionality similar to CW/WebbMe:
- Linear topics composed of HTML messages
- View topics by new messages/unread/all messages/hidden topics/archived topics
- Topics can be deleted/archived/made read-only by the conference host
- Topics can be hidden from a user's personal view
- Individual posts can be "hidden" or "scribbled" by owner or conference host
- Posts can be previewed, with spellchecking and HTML formatting
- Files can be "attached" to posts (up to 1 Mb in size)
- Enhancements to existing conference features:
- Full text search of posts within a conference
- Conference-level "bozo filters"
- Individual posts can be "nuked" without a trace by the conference host
- Later, replace other CW/WebbMe functions:
- Activity logs
- Instant messaging and chat (use Jabber)
- Calendaring
- Newsletters via e-mail
- Features from CW/WebbMe we won't do:
- Web hosting
- Web-based email
- Blue sky features:
- Output uses XML and gets formatted into [X]HTML via XSLT; "themeable"/"skinnable" interface
- Conferencing/other functionality available via XML-RPC or SOAP calls
- News page creation (see Slash, Squishdot, Scoop)
- Member trust metrics (see Slashdot "karma," Scoop "mojo," Advogato distributed trust metric)
(Feature indefinitely shelved at the request of the EMinds community)
- User diary pages (see Advogato, Kuro5hin)
- Moderated discussions (see Slash, Scoop)
- Collaborative database facility (see Wiki, Everything2)
- Content management/distributed publishing
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:
- 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.
- 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.
- Refactoring of database access, to eventually allow the use of databases other than MySQL, especially
ones which employ stored procedures.
- Improved search capabilities for posts, possibly employing the Lucene full-text search engine.
- 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.
- 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.
- 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.