CSMS - Short Term Plans |  print-friendly version |
by Ross D. Gardler
- Introduction
- 0.1 release
- 0.2.x release
- 0.3.x release
- 0.4.x release
- 0.5.x release
- 0.6.x release
- 0.7.x release
- 0.8.x release
- And onwards...
Introduction
This document outlines the plans for the CSMS project in the forseeable future. There is a separate document detailing our Long Term Plans .
0.1 release
- Additional Error Checking
- An extra step will be inserted into the events generation process in the Fantasy Sports Module, this will enable rules to be encoded to verify the generated scores, for example, total goals scored by a team should be equal to the number of goals identified in the result event.
0.2.x release
- Move to a core/module architecture
- The core doesn't really exist yet. What we have is a fantasy sports module. This release will see the introduction of the core. Instead of the user selecting a game that they want to see the scores on the core will be aware of all the games due to have been played by that time and calculate them.
0.3.x release
- Introduce team management
- Now that we have a core system and a sports module we can start thinking about teams and leagues. So in this release we will bring team management into play. We will support substitutions and transfers in this release.
0.4.x release
- League Management Facilities
- Now that we have the concept of teams we can start to publish league placings.
0.5.x release
- Move to a Cocoon Portal based system
- Move the user interface to a Cocoon web app. This will remove the need to install any software in order to use the system (although admittedly it will make it more difficult for people to install it for themselves should they want to hence the embedded jetty release after this one).
- Make available to Fanfoot.com players
- At this point the application will provide all major team management facilites. Testing at this point can be performed by the Fanfoot.com players.
0.6.x release
- Allow unconfirmed/confirmed event status
- Events should have a status flag that enables them to be marked as official or unofficial. There also needs to be a flag to indicate when an event has been queried by someone. Initially all events are unofficial, however, they are used to calculate published (unofficial) results. On a given day and time, all events that have not been queried are converted to official. The queried flag is used to indicate that someone thinks the event may be an error. The league administrator is asked to verify these events before they become confirmed. This is to allow scores to be gathered from "unnoficial" sources which will sometimes be faster than the "official" sources whilst still
- Embed Jetty server
- By embedding the jetty server in one of the releases we will be able to build a distribution that will run in full client/server mode with only the need to install Java.
0.7.x release
- Move to (Xindice?) database
- At present all data is stored in XML files, however they are being accesses through a URI. Therefore, we can no leverage Cocoons power to replace these files with a Xindice's XML database without the need to rewrite any code (theoretically at least)
0.8.x release
- Refactoring
- No new features will be added but the design of the system will be improved.
This release will be the first one that sees an (almost) stable core/module structure and API. It is this releae that we will start to really push to other projects for collaboration. Once this core infrastructure is in place the possible additions to the system are immense and so opportunities for multiple developers start to emerge.
And onwards...
From here we will plan the featureset to include in the 1.0 release by revisiting both our long and short term plans.
