org.melati Implementation Plan (document $Revision: 1.1 $)

# `org.melati` Implementation Plan (document $Revision: 1.1 $)

This document sets out the time and resources available and how they are to be deployed in completing the system. See also the system's master QA document.

## Scope

This document covers development of Melati up to the initial alpha release (0.1). For its current quality level, see the indicator below.

## Phasing of deliverables

The implementation will be divided into the following phases:

Deliverables | Target date
--- | ---
Basic persistence mechanism, in a form in which Paneris and other developers can evaluate it easily: including DSD processor and database creator, access control, cacheing, transactions, user guide, but not including any kind of web or templating interface | Sat, 12 Feb 2000
Basic templating mechanism, for evaluation: generation of displays and controls for text and numeric fields and for dropdowns, but no Javascript validation | Tue, 15 Feb 2000
Incomplete admin system, for evaluation: display/edit single records, with Javascript validation | Thu, 17 Feb 2000
Version 0.1. Basic admin system, with paged selection of records by field value `template', but no changing of database structure. | Sat, 19 Feb 2000

DB structure change is in fact probably not a large job, but we're trying to be conservative so as to reduce the chance of disappointing anyone.

Deliverables and target dates for 0.2 and later versions will be decided once version 0.1 has been evaluated.

## Platform

The hardware and software used in the system will be:

Linux 2.2/i586, Blackdown JDK1.1.7, Apache 1.3.3, JServ 1.0, Webmacro 0.89.1, Postgres 6.4 (see the requirements analysis)

## Task breakdown

The implementation of the system is divided into the following bite-sized tasks (see the internals description):

### Persistent store

#### Basic data structures

`Database`, `Session`, `Table`, `Type` hierarchy, table rows, value-bundled-with--type (provisionally `Field`)

`User`, `UserGroup`, `Capability`, `SettableCapability`

#### Processor for DSD

Parsing structure definition file, and generating Java code for the base classes and for the database structure the app expects to find.

#### Database schema inspector/creator

Looking at the `DatabaseMetaData` to make sure that it has a minimum set of tables and fields consistent with the data structure definition, create any that are missing, and find out what other (generic) tables and fields it contains.

- all fields present with right types
- all indexes present with right uniqueness attributes
- (if possible: nothing weird going on like defaulting fields)

#### Cacheing

Storing table rows that come in (in full), up to a certain maximum number per table. (What's the heuristic for flushing them?) Adding extra cache rows per non-committing session (no limit, or at least need some way to record that the row has been changed without ever forgetting), and moving them to the committed cache at the end.

#### Searching/retrieval

Retrieval by TROID from table, `SELECT` within a table, non-object non-cached `SELECT` on whole database.

#### Subsets

Triggering update of subset's list when table is changed (or, at least, marking it dirty). Vice versa.

#### Persistent store user guide

How to use it, for the programmer.

### `Application' software

#### Admin system

Port the current JAL admin system to Melati. In the timetable below, this task is divided into two parts.

#### User self-management

Port the current JAL login and password change system to Melati.

## Timetable

### Timings

The tasks involved in the implementation will (provisionally) be carried out as listed in the table below. Most of the work will be done by williamc, but the availability of mylesc and timp will be investigated in regard to the porting of the JAL admin system, of which they have more experience than the aforementioned williamc. timj, who actually wrote it, will be consulted but is very busy with a different project.

Task | Developers | Time needed | Target date
--- | --- | --- | ---
Basic data structures | williamc | 7 hours | Sun, 6 Feb 2000
Get infrastructure running on my boxes | williamc | 3 hours | Sun, 6 Feb 2000
Searching/retrieval; cacheing; transactions | williamc | 12 hours | Tue, 8 Feb 2000
Processor for DSD | williamc | 7 hours | Wed, 9 Feb 2000
Database schema inspector/creator | williamc | 6 hours | Thu, 10 Feb 2000
Persistent store user guide (brief) | williamc | 6 hours | Fri, 11 Feb 2000
Deliver: basic persistence mechanism | williamc | 1 hour | Sat, 12 Feb 2000
Text templating (display and input) | williamc | 5 hours | Mon, 14 Feb 2000
Dropdown templating | williamc; mylesc? | 2 hours | Tue, 15 Feb 2000
Deliver: basic templating mechanism | williamc | 1 hour | Tue, 15 Feb 2000
Figure out how a servlet/webmacro app determines user ID (blush) | williamc | 1 hour | Tue, 15 Feb 2000
Javascript validation | williamc; mylesc? | 7 hours | Wed, 16 Feb 2000
Port admin actions tables (but not altering DB structure), display, edit (except for `UploadURL`), update | williamc; mylesc? | 6 hours | Thu, 17 Feb 2000
Port admin actions update multiple, select, briefselect (whatever that is) | williamc; mylesc? | 4 hours | Fri, 17 Feb 2000
Deliver: basic admin system | williamc | 1 hour | Sat, 19 Feb 2000
Subsets | williamc | 3 hours | tbd

### Critical dependencies and fallback possibilities

Work on the admin system only makes sense once the persistent store is finished. The fallback is to deliver the persistent store only.

## Development resources

### Developers

The developers and designers required are:

William Chesters <williamc@paneris.org>; other Paneris developers will be invited to help with porting the administration system.

### Hardware

The hardware which must be in place for development to proceed are:

William's boxes and paneris.org: no problem.

### Software

The software which must be bought for development to process is:

None.

## Risk analysis

The obvious ways in which the system might end up being late are:

... contingency plans?

## About this document

### Authors

William Chesters <williamc@paneris.org>

Most recent CVS $Author: timp $ @paneris.org

### Quality

The current quality level of this document is: Alpha.

Scrappy, unreliable at the moment, and subject to revision as I get a clearer idea of what each task involves.

### Readership and purpose

- The project leader should at least be confident that the developers believe the timescales are achievable.
- The developers should understand what they are being asked to do.
- The customer is welcome to peruse the plan but isn't required to---except that their attention is drawn to any tasks assigned, as it were, to them.

### History

The important points in the life of this document are listed below (for everyday update information, consult its CVS log).

Date | Event
--- | ---
(not yet) | Approved at release quality level by ...

$Log: ImplementationPlan.html,v $
Revision 1.1 2005/11/21 22:01:49 timp
Moved from site/doc
Revision 1.12 2000/02/29 09:53:02 williamc
Finish recovering from disaster; point out in the docs that you can 'add methods to table rows'