ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001115.txt
(Generate patch)

Comparing projects/cms/documentation/minutes/minutes-20001115.txt (file contents):
Revision 1.1 by ab11, Wed Nov 15 14:47:38 2000 UTC vs.
Revision 1.3 by tdb, Wed Nov 15 19:10:14 2000 UTC

# Line 1 | Line 1
1   Minutes of meeting 15/11/00 @ 11am
2 < Locate UKC Computer Science Meeting Room
2 > Location: UKC Computer Science Meeting Room
3  
4   Present: ab11, ajm4, pjm2, tdb1
5   Absent: None
6  
7 < Meeting postponed until firealarm finishes. It is noted
8 < that Ash and Paul would have been burnt alive if there
9 < was a real fire.
7 > Meeting postponed until firealarm finishes. It is noted that
8 > Ash and Paul would have been burnt alive if there was a real
9 > fire.
10  
11   Meeting re-started at 11:20am.
12  
13 < Discussed the XML packet life problem. This has been
14 < identified as a problem because corba passes references
15 < to objects making it hard to determine when the object
16 < should be distroyed.
13 > Discussed the XML packet life problem. This has been
14 > identified as a problem because corba passes references to
15 > objects making it hard to determine when the object should
16 > be distroyed.
17  
18   Paul begins implementation of a quotes page.
19  
20   Paul suggests that packets should be stored in a queue
21 < structure, with 2 integers indicating how far through
22 < the queue each accessing function has got (from the start
23 < of the queue). This should be more efficicent than
24 < storing flags inside each of the XML packet objects.
21 > structure, with 2 integers indicating how far through the
22 > queue each accessing function has got (from the start of the
23 > queue). This should be more efficient than storing flags
24 > inside each of the XML packet objects.
25  
26 < Someone needs to find out if you can 'clone' an object
27 < over corba. This would solve a lot of local copy problems.
26 > Someone needs to find out if you can 'clone' an object over
27 > corba. This would solve a lot of local copy problems.
28  
29   Discussion of whether UDP packets should be numbered or
30   timestamped proved controversal. In the end it was decided
# Line 33 | Line 33 | and a timestamp (as defined by the host). It is theref
33   important that the host's time is setup accurately by the
34   sysadmin.
35  
36 < Meeting concluded @ 12:40
36 > The whole issue of packet content is more of a host & client
37 > design issue than a server issue.
38 >
39 > Meeting concluded @ 12:40
40 >
41 > Meeting continued @ 12:45 by a tree
42 > Present: ajm4, pjm2, tdb1
43 >
44 > Discussion continued about the design of the filter system.
45 > The whole issue of how and where packets will be stored
46 > within the system needed clearing up before implementation
47 > could continue.
48 >
49 > It was noted that the key function of the filter (given it's
50 > called a "filter") is to remove any packets of data it sees
51 > fit. With this in mind it was decided that the data could be
52 > passed on in text (or rather XML) format through the child
53 > filters.
54 >
55 > This would work as follows in a child filter. Data would be
56 > recieved by one of two means, UDP or CORBA. The hosts would
57 > be sending UDP to the filter, and other "up-stream" child
58 > filters would send over CORBA. Regardless, it will always be
59 > the same content - a String of XML. In essence this means
60 > that the filter will be sending and receiving exactly the
61 > same string of XML - without any conversion required.
62 > Internally it may be verified through "plug-ins" to see if
63 > it should be dropped, but this would just be a series of
64 > independant tests. Finally the string will be passed on if
65 > the plug-ins allow.
66 >
67 > This allows a chain of child filters going on and on in a
68 > tree-like fashion, which is what our original design
69 > permitted.
70 >
71 > Finally, the parent filter will recieve all the data from
72 > the child filters, and turn them into XMLPackets. These
73 > packets will be stored in some kind of data structure to be
74 > accessed by the various parts of the system.
75 >
76 > This solves many of our key problems.
77 >
78 > Meeting concluded @ 13:25
79 >
80 > Meeting continued @ 13:40 with iau
81 >
82 > iau briefly suggested that we alter the location of the
83 > database in our system. He suggested moving this into the
84 > parent filter, and then having the data passed straight on
85 > to the client interface.
86 >
87 > Nothing firm was decided, but it should be analysed further.
88 >
89 > Meeting concluded @ 13:55

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines