[Gb-ccb] suggested changes to ccb library

[Martin Shepherd]

On Mon, 11 Aug 2003, Brian Mason wrote:
>  a) reordered error messages: not a *requirement*, just something
>  that would be really nice. This will help us "throw out" (actually,
>  send to a log file, rather than our message system) messages of the
>  sort that we don't normally have in the message system.

An alternative that I would prefer would be to include another
enumerated argument with the log messages, specifying their type. I
would imagine that this would be easier at your end too. Would this be
acceptible?

>  b) a simulation mode of the actual ccb server; the goal here is
>  to have as much of the code as reasonably feasible be identical
>  between the simulation and the real thing. Again not an absolute
>  requirement, but something which we believe will pay off.

Agreed.

>  c) possibly, we would like to use the "scan control bit" which is
>  in the device interface, to control scans. We currently have
>  proposed a somewhat awkward mechanism in which the manager secretly
>  starts a scan just before a real scan (outlined in draft form in
>  the use cases Melinda and I wrote some time ago). Currently i believe this
>  bit is not accessible via the server, ie, the server interface hides
>  this bit and manipulates it itself (possibly for very good reasons:
>  we don't know, and would like to discuss it).

This bit needs to be toggled at precise instants that can only be
achieved by real-time interrupt handlers, so it would make no sense
for the server to have access to it. This is also only one of many
control bits, all of which need to be toggled with real-time
precision.

Could you tell me what the problem is that you are trying to work
around? Since new configuration information doesn't have any effect
until a new scan is started, I can't imagine a situation where one
might need a dummy intra-scan.

Beware that the internals of the device driver are liable to change
significantly, now that I am doing the hardware. The server interface
that I have provided to you is supposed to insulate you from those
changes, so if something in the server interface can't accomodate your
requirements, then I need to fix it at that level, without explicit
reference to the specific device-driver/hardware implementation.
Thinking about, and specifying server changes in terms of
hardware-level implementation details, such as the start-scan bit,
isn't a good idea.

Martin