i-scream documentation viewer
minutes-20001129.txt
Minutes of meeting 29/11/00 @ 3pm Location: UKC Computer Science Meeting Room Present: ab11, ajm4, pjm2, tdb1 Absent: None First up on the agenda was the database design. The group spent quite some time trying to come up with a simple, yet efficient database design... which proved quite tricky. Issues such as concurency, locking of tables came up, as well as whether we should classify certain data items as "key" and store them seperately. It was eventually decided that a rather stateless design would be implemented, at least at this stage. This was a two table design with one table containg a single entry "per xml packet", and another table containing a single row per data item. This meant that each row in the first table could be associated with one or more rows in the second. This design was not completely finalised, and Paul is to review this, and do some research into how this could be implemented. Ultimately the design needs to be tailored for our implementation, but not to the point that it restricts further growth and expansion of the system. Paul and Tim presented the Plugin system ideas. The group agreed that it was fine and should go ahead. It was put forward that the PluginManager should be a singleton class to avoid passing too many references around. This seems a good idea. Ash gave feedback on the current state of the java host. The group requested that the host be in a state that would permit all members to run it for testing the server with. Ash agreed to implement this. The meeting finished with a discussion on what the next stage of development should be. Ash agreed to polish off the java host so it implements all the functionality that the final host will have. AJ suggested that he and Tim look at the existing code, especially the filter, with the aim of tiding things up and standardising all the classes. Tim put forward that the code should be placed in packages at some point soon, as some parts of the system were getting messy, and a few classes were needed in multiple places. In the longer term development on the database front, and the client side should be started. Some design work will need to be done, but the group should be thinking about what could be done prior to the next meeting. The next meeting will happen on Monday, although the room is not booked. Arrangements should be made prior to the weekend.
