After having seen what works (paperwork) and what has problems (anything that requires a network connection to remote server) and what is limited (excel spreadsheets) it is time to come up with something better for automating roller derby. Here are the basic principles:
- Roller derby is recorded as a series of ordered event, not as fields in a database
- Individual paperwork works
- During a bout, there are very few centralized dependencies (scorekeepers aren't stopped if the lineup tracker's pencil breaks), and most of those are informal ("what jam are we on?") or non-real time (jammer ref signals points, scorekeeper confirms and records, reports to scoreboard operator). Imagine what a bout would be like if every NSO had to tell the CHNSO what was going on and the CHNSO was the only one who could record stuff.
- XML files are not perfect by a long shot, but they are far smaller than spread sheets and far better at storing arbitrary data (and much easier for later data analysis and support by multiple tools)
- Note taking for "weird stuff" is a good thing, there is always weird stuff
To this end, I'm creating a "DerbyOS", which will be a series of products, protocols, and file formats. All of the protocols and file formats will be "open" - documented for anybody to use. You want to write a penalty box timer that automatically starts/stops the timers in sync with the scoreboard? You'll be able to do it. Some of the products will be Open Source, some will be commercial (after all, one of best ways to encourage somebody to support a product is to pay them).
The first building block is an XML schema "DerbyXML" (flat track derby xml). A typical 1.6 meg Statbook file becomes a 20k xml file (and removes the nightmare of constantly updating spreadsheet parsers to support the fact that an extra column was added to one of the pages). Clients can general their own portion of the XML files and be merged together (with, of course, bout reconciliation techniques that catch inconsistent data).
The second building block is the design of a network for bout time data collection, based on a distributed computing model, rather than a client/server model. Each node can collect their own data, and share it with all other node. We want to follow the "paperwork" model for each position, making it easier to transition from paperwork to computer - we don't need to take a significant portion of screen real-estate to display the ruleset used in the bout to all the NSOs.
This network communication becomes a "smart" derby platform (not unlike "Smart Home" automation platforms, only with a realistic scope). You can add additional clients to do things as needed. There could also one "CHNSO" node that can record all that information, and flag problems right away - let's face it, sooner or later a lineup tracker and a scorekeeper are going to write down a different jammer (and figuring out who is "correct" later is difficult at best, so getting a red flag right away is best). There could be an "announcers real-time stats" client. None of these extra clients require updating a server to a new version, or even require the server team to implement features.
The current plan is to use ZeroMQ for the messaging platform, which will allow for clients written in a variety of platforms/languages. The messages themselves will be DerbyXML event element, which are exchanged as they happen (or, in the case of a client crashing, it could ask for "what has happened"). Any client can, if it desires, could collect a full bout worth of DerbyXML by the end of the bout.
These are the goals for DerbyOS.