The membership management system will be implemented in Smalltalk. The initial versions will run in VisualWorks using the Hyper HTTP server and PostgreSQL DBMS.
In many ways, the MMS is a workflow system. The workflow is a series of "Actions". Each actions has three phases of it's life:
- Request: The action is requested. This creates an action request in the database and thus schedules the action for a specific date in the future. The action can do work in this phase but it must not involve anything slow (e.g. sending email or working with OpenPGP keys).
- Execute: The action does it's work. This can (and often does) involve slow things like email and OpenPGP key handling. This phase is in turn broken into three steps:
- Prepare: Here the action gets ready to do things that will update the database. For example, downloading OpenPGP keys and checking them. This is the action working out what needs to happen.
- DB Update: Here the action modifies the business objects, requests other actions and either reshedules itself or concludes itself. This is the action making things happen.
- Post Update: Typically an action sends out email messages and gives newly requested actions the chance to send out emails too in this stage. This is the action letting people know what has happened.
- Conclude: This typically just means that the action request is marked as complete. This phase must happen with a database transaction and may be invoked by the Web UI or as part of the execute phase of an action.
We need to use a relational database so that the information in the MMS is easily available to other OpenSkills systems. The flatness of the data structures in the system makes an RDBMS a reasonable solution. There are a number of ways to go with O-R mechanisms. For now, only two options are being considered, Glorp and DIY SQL:
- Glorp. This is the upcoming free O-R mapping layer for Smalltalk initially being developed in VisualWorks.
- Larger learning curve (but will pay back later)
- Adds to the porting burden if/when MMS moves to GemStone (or anything else)
- Likely to scale better than DIY
- Can hassle Alan if there are problems
- Will be a good test for the PostgreSQL drivers
- Embed SQL. This is the Hit It With a Hammer approach.
- Probably more immediate results. Instant gratification
- More obviously portable (e.g. we don't need to port GLORP to GemStone)
- Have to sove all kinds of mapping problems anyway