| 1 |
Minutes of Meeting, 18/10/2000 @ 2:00pm |
| 2 |
Location: UKC Computer Science Meeting Room |
| 3 |
|
| 4 |
Present: ab11, ajm4, pjm2, tdb1 |
| 5 |
Absent: none |
| 6 |
|
| 7 |
This meeting was spent producing a features list for review |
| 8 |
by jc. This list can be found elsewhere. The idea behind |
| 9 |
this list was to summarise what the end product was going to |
| 10 |
be link, from our current plans, and to ensure that it met |
| 11 |
with the initial requirements of jc. |
| 12 |
|
| 13 |
Also produced was a revised diagram of the system, taking |
| 14 |
into account the following alterations from the original |
| 15 |
diagram of 05/10/2000. |
| 16 |
|
| 17 |
- Web interface scrapped. |
| 18 |
It was decided that this was no longer required, since |
| 19 |
any scripting language would connect directly to the |
| 20 |
database to retrieve information. |
| 21 |
|
| 22 |
- Collector/Filter redefined. |
| 23 |
The collector/filter part of the server was redefined |
| 24 |
such that a hierachy of them could be arranged to |
| 25 |
spread the load of incoming data. Ultimately all data |
| 26 |
goes through the last (and main) one, but it does at |
| 27 |
least give an extra layer of organisation for the |
| 28 |
administrator. ie. machines could be grouped (by |
| 29 |
site?) and have their own collector/filter which |
| 30 |
reports back to a central system - almost like a proxy. |
| 31 |
|
| 32 |
- DBI (DataBase Interface) added. |
| 33 |
This interface connects directly to the database, and |
| 34 |
is therefore the only part of the system that need know |
| 35 |
the exact workings of the database. It can also be |
| 36 |
given funtionality to decide what information will be |
| 37 |
stored in the database, and how it will be done. |
| 38 |
|
| 39 |
- Clients split to "real-time" and "historic" |
| 40 |
The clients are split into two groups. Firstly the |
| 41 |
"real-time" clients (on the bottom left) connect |
| 42 |
directly to the system via a client interface. This |
| 43 |
allows the clients to receive up-to-date information |
| 44 |
directly, rather than through the database. Secondly, |
| 45 |
the "historic" clients connect to the database, either |
| 46 |
directly or via an interface, and allow information |
| 47 |
about the history of a machine to be viewed. Both of |
| 48 |
these types of clients could actually be implemented in |
| 49 |
one physical application, but the distinguishment has |
| 50 |
been made at this level. |
| 51 |
It should also be noted that the "real-time" clients |
| 52 |
have information pushed to them by the server, whilst |
| 53 |
the "historic" clients pull information themselves. |
| 54 |
|
| 55 |
This system can be seen in the following diagram; |
| 56 |
|
| 57 |
/documentation/minutes/system-20001018.gif |
| 58 |
|
| 59 |
The meeting was concluded at 5pm. |
