| 1 |
|
Minutes of Meeting, 13/11/2000 @ 14:00 |
| 2 |
< |
Location: Eliot College, room E3E |
| 2 |
> |
Location: Eliot College, E3E room 8 |
| 3 |
|
|
| 4 |
|
Present: ajm4, tdb1 |
| 5 |
|
Absent: none |
| 19 |
|
isn't seen to be a real problem though, as it was only going |
| 20 |
|
to be a "funky" extra ;-) |
| 21 |
|
|
| 22 |
+ |
[tdb1: this will also solve security issues with |
| 23 |
+ |
unauthorised third parties changing settings.] |
| 24 |
+ |
|
| 25 |
+ |
|
| 26 |
|
Next point was whether or not we would support elements |
| 27 |
< |
being able to be updated without restarting them ie, a host |
| 27 |
> |
being able to be updated without restarting them, ie. a host |
| 28 |
|
would be able to detect its configuration has changed and |
| 29 |
|
adjust accordingly. The method chosen was to use the last |
| 30 |
|
modified date stamp of the configuration file as an |
| 36 |
|
configuration has been updated, and act accordingly. The |
| 37 |
|
methods: |
| 38 |
|
|
| 39 |
< |
long Configuration.getLastModifed() and |
| 40 |
< |
boolean Configurator.isModified(config) |
| 39 |
> |
long Configuration.getLastModifed() and |
| 40 |
> |
boolean Configurator.isModified(String conf, long curTime) |
| 41 |
|
|
| 42 |
|
where thus implemented and the configurator test class |
| 43 |
|
modified to include a test of this system. |
| 44 |
|
|
| 45 |
+ |
It should also be noted at this stage that a java 'long' is |
| 46 |
+ |
defined as a 'long long' in the IDL->Java mapping. |
| 47 |
|
|
| 48 |
|
|
| 49 |
|
The next item discussed was the CORBA IDL and general system |
| 73 |
|
a HostInit object to handle this intialisation. The first |
| 74 |
|
thing a Host does is obtain its configuration, this is done |
| 75 |
|
by the HostInit object obtaining the configuration of the |
| 76 |
< |
host its behalf. An initial protocol of how this system |
| 77 |
< |
works is as follows: |
| 76 |
> |
host on its behalf. An initial protocol of how this system |
| 77 |
> |
works is as follows (of course this is subject to later |
| 78 |
> |
alteration, but seemed like a "good idea at the time"): |
| 79 |
|
|
| 80 |
|
Host FilterManager.HostInit |
| 81 |
|
STARTCONFIG -> |
| 82 |
< |
<- OK | ERROR |
| 82 |
> |
<- OK | ERROR |
| 83 |
|
LASTMODIFIED -> |
| 84 |
< |
<- LASTMODIFIED |
| 84 |
> |
<- LASTMODIFIED |
| 85 |
|
DO { |
| 86 |
|
PROPERTY -> |
| 87 |
< |
<- VALUE | ERROR |
| 87 |
> |
<- VALUE | ERROR |
| 88 |
|
} UNTIL GOT CONFIG |
| 89 |
|
|
| 90 |
|
ENDCONFIG -> |
| 91 |
< |
<- OK |
| 91 |
> |
<- OK |
| 92 |
|
|
| 93 |
+ |
If there is an ERROR returned after STARTCONFIG, this |
| 94 |
+ |
indicates to the Host that there is no configuration |
| 95 |
+ |
available for it at this time. It may be possible to |
| 96 |
+ |
continue using default values, but this is up to the host |
| 97 |
+ |
configuration. Again, this is not a certain feature and |
| 98 |
+ |
should be discussed with other members of the group. |
| 99 |
+ |
|
| 100 |
|
If the property section returns an ERROR then this indicates |
| 101 |
|
to the host that that property requested doesn't exist, the |
| 102 |
|
Host will then deal with this either by ending with an error |
| 103 |
|
on the local system or by ignoring it if it can. |
| 104 |
|
|
| 105 |
< |
The above features where implemented. |
| 105 |
> |
The above features were implemented. |
| 106 |
|
|
| 107 |
+ |
|
| 108 |
+ |
|
| 109 |
|
The next item needed to be developed is an architecture for |
| 110 |
|
FilterParent's and FilterChild's, as the next stage of Host |
| 111 |
< |
initialisation is to be past a reference to a FilterChild. |
| 111 |
> |
initialisation is to be passed a 'reference' to a |
| 112 |
> |
FilterChild. This 'reference' will be a server and a port |
| 113 |
> |
and not a reference in the CORBA or Java way of thinking. |
| 114 |
|
|
| 115 |
|
It was noted that on a "heart beat" with the system, a Host |
| 116 |
|
should check to see if its configuration has changed. If it |
| 129 |
|
|
| 130 |
|
|
| 131 |
|
All code generated was placed in the "experimental" tree of |
| 132 |
< |
CVS, awaiting approval from other group members. |
| 132 |
> |
CVS, awaiting approval from other group members. It should |
| 133 |
> |
also be noted that although CVS records tdb1 as the |
| 134 |
> |
'checker inner', it was infact ajm4...as he was the king of |
| 135 |
> |
code during this meeting ;-p |
| 136 |
|
|
| 137 |
|
Many small bug fixes were made to the existing code. |
| 138 |
|
|
| 139 |
|
It was also noted that there is a need for coding standards. |
| 140 |
|
|
| 141 |
|
As we had reached an appropriate stage to end, and given the |
| 142 |
< |
late hour, it was decided to conclude the meeting. |
| 142 |
> |
late hour, it was decided to conclude the meeting. It was, |
| 143 |
> |
after all, nearly 7 hours of coding ;-) |
| 144 |
> |
|
| 145 |
> |
Since this meeting took place tdb1 has produced Makefiles |
| 146 |
> |
to allow easy compiling and configuration of the code. |
| 147 |
> |
|
| 148 |
|
|
| 149 |
|
Meeting was concluded @ 20:45. Next meeting booked for 11:00 |
| 150 |
|
on Wednesday, until 12:30. Meeting with iau @ 13:30 on that |
