| 1 |
tdb |
1.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. |
