i-scream documentation viewer
minutes-20001115.txt
Minutes of meeting 15/11/00 @ 11am Location: UKC Computer Science Meeting Room Present: ab11, ajm4, pjm2, tdb1 Absent: None Meeting postponed until firealarm finishes. It is noted that Ash and Paul would have been burnt alive if there was a real fire. Meeting re-started at 11:20am. Discussed the XML packet life problem. This has been identified as a problem because corba passes references to objects making it hard to determine when the object should be distroyed. Paul begins implementation of a quotes page. Paul suggests that packets should be stored in a queue structure, with 2 integers indicating how far through the queue each accessing function has got (from the start of the queue). This should be more efficient than storing flags inside each of the XML packet objects. Someone needs to find out if you can 'clone' an object over corba. This would solve a lot of local copy problems. This thought was rejected by iau in the meeting. Discussion of whether UDP packets should be numbered or timestamped proved controversal. In the end it was decided that each UDP packet should contain both a Sequence number and a timestamp (as defined by the host). It is therefore important that the host's time is setup accurately by the sysadmin. The whole issue of packet content is more of a host & client design issue than a server issue. It was mentioned that the logging system should be able to deal with verbosity levels, in a similar way to JacORB. This would allow trivial messages to be hidden most of the time. The possibility of multiple loggers might also want to be consider (eg. file log with high verbosity, and screen log with low verbosity, running in parallel). Meeting concluded @ 12:40 Meeting continued @ 12:45 by a tree Present: ajm4, pjm2, tdb1 Discussion continued about the design of the filter system. The whole issue of how and where packets will be stored within the system needed clearing up before implementation could continue. It was noted that the key function of the filter (given it's called a "filter") is to remove any packets of data it sees fit. With this in mind it was decided that the data could be passed on in text (or rather XML) format through the child filters. This would work as follows in a child filter. Data would be recieved by one of two means, UDP or CORBA. The hosts would be sending UDP to the filter, and other "up-stream" child filters would send over CORBA. Regardless, it will always be the same content - a String of XML. In essence this means that the filter will be sending and receiving exactly the same string of XML - without any conversion required. Internally it may be verified through "plug-ins" to see if it should be dropped, but this would just be a series of independant tests. Finally the string will be passed on if the plug-ins allow. This allows a chain of child filters going on and on in a tree-like fashion, which is what our original design permitted. Finally, the parent filter will recieve all the data from the child filters, and turn them into XMLPackets. These packets will be stored in some kind of data structure to be accessed by the various parts of the system. This solves many of our key problems. Meeting concluded @ 13:25 Meeting continued @ 13:40 with iau iau briefly suggested that we alter the location of the database in our system. He suggested moving this into the parent filter, and then having the data passed straight on to the client interface. Nothing firm was decided, but it should be analysed further. Meeting concluded @ 13:55
