ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001129.txt
Revision: 1.1
Committed: Thu Nov 30 23:55:57 2000 UTC (23 years, 4 months ago) by tdb
Content type: text/plain
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
Log Message:
Minutes from group meeting on 29/11/2000.

File Contents

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