ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
Revision: 1.4
Committed: Wed Nov 15 23:51:38 2000 UTC (23 years, 7 months ago) by tdb
Content type: text/plain
Branch: MAIN
Changes since 1.3: +9 -1 lines
Log Message:
A few small additions.

File Contents

# Content
1 Minutes of meeting 15/11/00 @ 11am
2 Location: UKC Computer Science Meeting Room
4 Present: ab11, ajm4, pjm2, tdb1
5 Absent: None
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.
11 Meeting re-started at 11:20am.
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.
18 Paul begins implementation of a quotes page.
20 Paul suggests that packets should be stored in a queue
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.
26 Someone needs to find out if you can 'clone' an object over
27 corba. This would solve a lot of local copy problems. This
28 thought was rejected by iau in the meeting.
30 Discussion of whether UDP packets should be numbered or
31 timestamped proved controversal. In the end it was decided
32 that each UDP packet should contain both a Sequence number
33 and a timestamp (as defined by the host). It is therefore
34 important that the host's time is setup accurately by the
35 sysadmin.
37 The whole issue of packet content is more of a host & client
38 design issue than a server issue.
40 It was mentioned that the logging system should be able to
41 deal with verbosity levels, in a similar way to JacORB. This
42 would allow trivial messages to be hidden most of the time.
43 The possibility of multiple loggers might also want to be
44 consider (eg. file log with high verbosity, and screen log
45 with low verbosity, running in parallel).
47 Meeting concluded @ 12:40
49 Meeting continued @ 12:45 by a tree
50 Present: ajm4, pjm2, tdb1
52 Discussion continued about the design of the filter system.
53 The whole issue of how and where packets will be stored
54 within the system needed clearing up before implementation
55 could continue.
57 It was noted that the key function of the filter (given it's
58 called a "filter") is to remove any packets of data it sees
59 fit. With this in mind it was decided that the data could be
60 passed on in text (or rather XML) format through the child
61 filters.
63 This would work as follows in a child filter. Data would be
64 recieved by one of two means, UDP or CORBA. The hosts would
65 be sending UDP to the filter, and other "up-stream" child
66 filters would send over CORBA. Regardless, it will always be
67 the same content - a String of XML. In essence this means
68 that the filter will be sending and receiving exactly the
69 same string of XML - without any conversion required.
70 Internally it may be verified through "plug-ins" to see if
71 it should be dropped, but this would just be a series of
72 independant tests. Finally the string will be passed on if
73 the plug-ins allow.
75 This allows a chain of child filters going on and on in a
76 tree-like fashion, which is what our original design
77 permitted.
79 Finally, the parent filter will recieve all the data from
80 the child filters, and turn them into XMLPackets. These
81 packets will be stored in some kind of data structure to be
82 accessed by the various parts of the system.
84 This solves many of our key problems.
86 Meeting concluded @ 13:25
88 Meeting continued @ 13:40 with iau
90 iau briefly suggested that we alter the location of the
91 database in our system. He suggested moving this into the
92 parent filter, and then having the data passed straight on
93 to the client interface.
95 Nothing firm was decided, but it should be analysed further.
97 Meeting concluded @ 13:55