| 1 |
tdb |
1.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. |
