| 1 |
Minutes of meeting 29/11/00 @ 3pm |
| 2 |
Location: UKC Computer Science Meeting Room |
| 3 |
|
| 4 |
Present: ab11, ajm4, pjm2, tdb1 |
| 5 |
Absent: None |
| 6 |
|
| 7 |
First up on the agenda was the database design. The group |
| 8 |
spent quite some time trying to come up with a simple, yet |
| 9 |
efficient database design... which proved quite tricky. |
| 10 |
Issues such as concurency, locking of tables came up, as |
| 11 |
well as whether we should classify certain data items as |
| 12 |
"key" and store them seperately. |
| 13 |
|
| 14 |
It was eventually decided that a rather stateless design |
| 15 |
would be implemented, at least at this stage. This was a two |
| 16 |
table design with one table containg a single entry "per xml |
| 17 |
packet", and another table containing a single row per data |
| 18 |
item. This meant that each row in the first table could be |
| 19 |
associated with one or more rows in the second. |
| 20 |
|
| 21 |
This design was not completely finalised, and Paul is to |
| 22 |
review this, and do some research into how this could be |
| 23 |
implemented. Ultimately the design needs to be tailored for |
| 24 |
our implementation, but not to the point that it restricts |
| 25 |
further growth and expansion of the system. |
| 26 |
|
| 27 |
Paul and Tim presented the Plugin system ideas. The group |
| 28 |
agreed that it was fine and should go ahead. It was put |
| 29 |
forward that the PluginManager should be a singleton class |
| 30 |
to avoid passing too many references around. This seems a |
| 31 |
good idea. |
| 32 |
|
| 33 |
Ash gave feedback on the current state of the java host. The |
| 34 |
group requested that the host be in a state that would |
| 35 |
permit all members to run it for testing the server with. |
| 36 |
Ash agreed to implement this. |
| 37 |
|
| 38 |
The meeting finished with a discussion on what the next |
| 39 |
stage of development should be. Ash agreed to polish off the |
| 40 |
java host so it implements all the functionality that the |
| 41 |
final host will have. AJ suggested that he and Tim look at |
| 42 |
the existing code, especially the filter, with the aim of |
| 43 |
tiding things up and standardising all the classes. Tim put |
| 44 |
forward that the code should be placed in packages at some |
| 45 |
point soon, as some parts of the system were getting messy, |
| 46 |
and a few classes were needed in multiple places. |
| 47 |
|
| 48 |
In the longer term development on the database front, and |
| 49 |
the client side should be started. Some design work will |
| 50 |
need to be done, but the group should be thinking about what |
| 51 |
could be done prior to the next meeting. |
| 52 |
|
| 53 |
The next meeting will happen on Monday, although the room is |
| 54 |
not booked. Arrangements should be made prior to the |
| 55 |
weekend. |
