| 1 |
tdb |
1.1 |
Minutes of meeting 15/01/2001 @ 2pm |
| 2 |
|
|
Location: UKC Computer Science Meeting Room |
| 3 |
|
|
|
| 4 |
|
|
Present: ab11, ajm4, pjm2, tdb1 |
| 5 |
|
|
Absent: None |
| 6 |
|
|
|
| 7 |
|
|
The meeting started with a review of the clients. Everyone |
| 8 |
|
|
was impressed with the status of them. Work is to continue |
| 9 |
|
|
over the next week or so to complete them. |
| 10 |
|
|
|
| 11 |
|
|
The issue of the server locking up was to be addressed. |
| 12 |
|
|
However, in testing during the meeting it was decided that |
| 13 |
|
|
it was a problem in the ClientInterface - an issue which is |
| 14 |
|
|
still being resolved. Further investigation was put off |
| 15 |
|
|
until this has been completed. |
| 16 |
|
|
|
| 17 |
|
|
Data to be grabbed was discussed. This is becoming an |
| 18 |
|
|
important issue as the clients are requiring more precise |
| 19 |
|
|
details. It was decided the the "grabbing" part of the host |
| 20 |
|
|
should be seperated, for now, from the main program. A Perl |
| 21 |
|
|
program will be written which will parse output from various |
| 22 |
|
|
system commands (which ports for different OS's) and output |
| 23 |
|
|
it in ascii for use by the host application. This will also |
| 24 |
|
|
aid porting of the host into C++, which is continuing. It is |
| 25 |
|
|
hoped that this "grabbing" code will be moved to C++ |
| 26 |
|
|
eventually, but this is a good stop gap, and will also work |
| 27 |
|
|
well if moving to C++ cannot be completed. |
| 28 |
|
|
|
| 29 |
|
|
The group expressed concern on the progress of the host |
| 30 |
|
|
application. With work moving fast on the client side a |
| 31 |
|
|
solid and reliable host was required. The current host is |
| 32 |
|
|
unpredictable and can crash unexpectedly. These issues are |
| 33 |
|
|
being addressed. The group also requested that the server be |
| 34 |
|
|
"completed" for a release soon, allowing it to be left |
| 35 |
|
|
running on Killigrew[1] for host and client testing. |
| 36 |
|
|
|
| 37 |
|
|
Another issued raised was the client to server protocol. A |
| 38 |
|
|
protocol needs to be clearly defined to make server and |
| 39 |
|
|
client development easier. AJ & Tim discussed this and will |
| 40 |
|
|
produce a spec soon. |
| 41 |
|
|
|
| 42 |
|
|
Tim raised the issue of Makefiles. The server benefits |
| 43 |
|
|
greatly from some extended Makefiles, and the other |
| 44 |
|
|
components could use some basic ones to allow quick & easier |
| 45 |
|
|
building. This will be looked into. |
| 46 |
|
|
|
| 47 |
|
|
Finally, it became apparent that the util package of the |
| 48 |
|
|
server contains code required in the clients. It was agreed |
| 49 |
|
|
that this package should be available seperately in a JAR |
| 50 |
|
|
file for use in the clients. Tim agreed to do this, |
| 51 |
|
|
arranging Makefiles and changing code to remove dependencies |
| 52 |
|
|
with the rest of the server. |
| 53 |
|
|
|
| 54 |
|
|
The next meeting will be on Monday afternoon at the usual |
| 55 |
|
|
time. The meeting room is booked 2pm to 5pm. |
| 56 |
|
|
|
| 57 |
|
|
[1] - Killigrew is a FreeBSD machine made available by Tim. |
| 58 |
|
|
Continued use is not guaranteed, but it does provide |
| 59 |
|
|
the group with a "shared" user for running the server. |
| 60 |
|
|
This makes stopping/starting/controlling the server |
| 61 |
|
|
possible by anyone in the group - something not |
| 62 |
|
|
available to us on Raptor. |
