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