While writing the design for the CDEV Gateway and the CDEV Archiver
we discovered that in some cases it is difficult to identify when
a multi-part request is done sending. This makes it difficult for
a developer to know when he can delete data structures that he is
maintaining in order to manage the callbacks.
In the example of the "monitorOn" request, a "monitorOn" is sent to
a device using the sendCallback method and may generate an inifinite
number of responses depending on the number of changes to the monitored
device. The monitoring is terminated when the caller sends a
"monitorOff" message. Notably, there is currently no mechanism to
inform the developer's "monitorOn" callback that it will be receiving
no more responses associated with that request and it can safely delete
any data that it has allocated to manage the results. (The word "safely"
depends entirely on how the developer wrote his code).
Currently, the developer is expected to know that any message that he
sends might generate a multi-part response, and behave accordingly...
This is decidedly NOT flexible and NOT object oriented.
Chip and I examined a number of solutions that involved sending
additional callbacks and modifying the structure of the callback
function in order to inform the developer that the data was going
to stop flowing - however, most of these design's would certainly break
existing code and only cause confusion.
Our most recent solution was to add a static value to the cdevCallback
class named "partialResult"... it would be a boolean value that would
indicate if the result that was received by the callback represented
all of the data or if it was an interim result and more data can be
expected.
In addition, the method "fireCallback" would be added to the
cdevCallback class and would have the following prototype...
void fireCallback(int status,
void * userarg,
cdevRequestObject & req,
cdevData & data,
int partial = 0);
You'll recognize thge first four parameters as those used by the
cdevCallbackFunction, the last value will be used to set the
partialResult flag. This method will reset the partialResult flag
to zero prior to returning.
The main impact of this change would be on those of you who have
already developed services, the fireCallback method with a "partial"
of 1 would have to be used when executing the callbacks for any
multipart messages (such as monitorOn) that you have already developed.
If anyone has a more dignified solution to this problem, I would very
much appreciate hearing about it...
Walt
--
=============================================================
Walt Akers Voice: (757)269-7669 E-Mail: akers@cebaf.gov
Thomas Jefferson National Accelerator Facility
12000 Jefferson Avenue, MS 16A
Newport News, Va 23606
=============================================================