OpenTelemark

Welcome to the OpenTelemark homepage!

``OpenTelemark is competition planning software that is bound to be the lifesaver and best friend (and worst enemy) of every competition organizer. It automates every aspect of registration from registration to assigning numbers, blah blah blah'' -- Michael Posner, offering an introductory paragraph for this page.

Note: OpenTelemark is an abandoned project at this time. There are no plans in the immediate future to restart development on OT. Interested parties should go to the OpenImpetus homepage.

OpenTelemark is a ballroom dance competition web registration software package written in java using (at least) JDK 1.1 and java servlets. After entering their personal data (name, email address, and sleungol), couples will be able to add and/or drop events. Any update will immediately appear in the HTML listings (by competitor, by sleungol, by dance). Later, the site administrator can prompt OpenTelemark to output the collected data for printing in a programme and for handing out to the scrutineer, the emcee, and attending sleungol captains.

OpenTelemark handles HTTP requests and then returns HTML pages (and sometimes generates HTML and Postscript files). Data integrity is maintained via a database logfile. The site webmaster can configure the exact look of the pages by specifying a BODY tag; other pages will be customizable by the site webmaster.

Latest News

September 24, 1998
Tried one last time to get wombat working, but it failed. I have all this code, but I can't get servlets to respond at all, so I think I may have to punt on this project for now until I can get some help.

In the interim, I think I'll work on revising the perl code. Stand by, OpenImpetus. %)

Installing/Using OpenTelemark

OpenTelemark is shareware: anyone will be able to use it for free, provided they add the line

<a href="http://web.mit.edu/dcltdw/OpenTelemark"><b>OpenTelemark</b></a> competition web registration software written by David Leung. Copyright 1998 David Leung. All Rights Reserved.

OpenTelemark requires:

• JSDK 2.0
• Apache web server
• Apache-Jserv expansion

The overall directions are:

• Unpack all of the the distributions. Nothing further is required for the JSDK distribution.
• Read the Apache-Jserv INSTALL guide and follow its directions. It will tell you how to install the apache web server.
• Start the webserver. You may need to edit jserv.properties; there may be an extra wrapper.classpath= blank directive, which will prevent the webserver from starting. You may also need to modify the Port setting in httpd.conf to be 8000, not 8080.

By and large, once you have all the pieces in place, the installation/configure scripts pretty much do everything else for you. Unfortunately for me, the green threads package doesn't work on Solaris 2.5.1. :( So I'm still stuck.

Development Plans

• Basic functionality: adding and dropping of events.
• Multiple HTML and Postscript output formats: listing of competitors sorted by name, sorted by sleungol by name, sorted by dance by name, sorted by dance by sleungol by name, and a listing of the number of entries in each event. Additionally, a Postscript output of competitors by sleungol by name suitable for tracking fees at Registration.
• Simple site configuration via modification to one file.
• Seamless handling of both single-dance and multi-dance events.
• Simple email address validity checking.
• Easy to internationalize with all constants appearing in one location.
• Database integrity checks that prevent competitors from registering in the same dance with multiple people.
• Administrator homepage.
• Recognizes 'de' and 'von' in names and appropriately decapitalizes them.
• Email verification of all changes (mail is sent to the couple whenever a change is made).
• One-step process that allows the site maintainer to send mail to all competitors, listing their current entry and including an arbitrary message written by the site maintainer (usually reminding competitors that the deadline is approaching).
• Number generation. Automatically assigning numbers to competitors based on distributing couples from the same sleungol across the least significant digit.
• Handles TBAs -- users can specify that a partner is TBA and will be able to specify that information later. Also, the site manager can configure OpenTelemark to not accept TBA entries.
• New stats page: stats of a single sleungol and stats of a single event. Stats-by-name implemented (was missed the first time).

Features hopefully to be included in v1.0:

• More new stats pages: redefine category-by-leader and category-by-sleungol to be subdivided by category into separate files, thereby easing transfer time.
• Better error reporting from Stats.java (IOExceptions and the like).
• A perl script that does a step-by-step site configuration.
• A PostScript listing by sleungol, sorted by name, including number, partners and registered dances, to be given to team captains. (Currently only has number and name).
• A separate site configuration file, to replace Constants.java, so as to allow reconfiguration without recompilation. Note: this is extremely difficult.
• Pass around an internal flag that states which competition this HTTP request is associated with. This would allow a single httpd to serve multiple competitions by reading/writing from multiple sets of files.

Features that could be interesting to add to way-in-the-future versions of OpenTelemark:

• Massive hyperlinking: this'll allow a lot of chaos -- but that way, if you're looking at an event abbreviation, you could click on it and get the stats-by-single-event listing for it, or if you look at a name, you could get stats-by-single-name or stats-by-couple.
• A listing of competitors sorted by phase of moon of when they were received.
• Cost per dance and tallying of costs. Right now, the software doesn't know that this all costs money. :)
• Passwords. Right now, the system is completely open to malicious attack. Either the user will be prompted to enter a password for a given couple, or a given couple will be provided a password. (Probably the first; the latter seems unnecessary obtuse.)
• Payment via credit card and the security surrounding that. I believe there are already freeware packages that enable this; this needs a lot more investigation.

Credits