| 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. This |
| 28 |
> |
thought was rejected by iau in the meeting. |
| 29 |
|
|
| 30 |
|
Discussion of whether UDP packets should be numbered or |
| 31 |
|
timestamped proved controversal. In the end it was decided |
| 34 |
|
important that the host's time is setup accurately by the |
| 35 |
|
sysadmin. |
| 36 |
|
|
| 37 |
< |
Meeting concluded @ 12:40 |
| 37 |
> |
The whole issue of packet content is more of a host & client |
| 38 |
> |
design issue than a server issue. |
| 39 |
> |
|
| 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). |
| 46 |
> |
|
| 47 |
> |
Meeting concluded @ 12:40 |
| 48 |
> |
|
| 49 |
> |
Meeting continued @ 12:45 by a tree |
| 50 |
> |
Present: ajm4, pjm2, tdb1 |
| 51 |
> |
|
| 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. |
| 56 |
> |
|
| 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. |
| 62 |
> |
|
| 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. |
| 74 |
> |
|
| 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. |
| 78 |
> |
|
| 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. |
| 83 |
> |
|
| 84 |
> |
This solves many of our key problems. |
| 85 |
> |
|
| 86 |
> |
Meeting concluded @ 13:25 |
| 87 |
> |
|
| 88 |
> |
Meeting continued @ 13:40 with iau |
| 89 |
> |
|
| 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. |
| 94 |
> |
|
| 95 |
> |
Nothing firm was decided, but it should be analysed further. |
| 96 |
> |
|
| 97 |
> |
Meeting concluded @ 13:55 |
