Cisco Cisco TelePresence MCU 4510 Developer's Guide
Revision numbers
Cisco TelePresence MCU Remote Management API Reference Guide
Page 86 of 89
Discovering record removal
The problem with only returning records in responses when they have changed is that if a record is
removed there is no way for the client to distinguish between it being removed and just not having
changed.
removed there is no way for the client to distinguish between it being removed and just not having
changed.
There are two solutions to this problem; the first is the listAll parameter and the second is described in
the next section. A client may periodically include the listAll Boolean parameter set to TRUE to
indicate that the MCU should return every record available. Enumeration limits still apply so multiple
calls using the standard enumeration protocol may be required. This allows a client to resynchronize
to the MCU, because it can safely assume that any record not returned by this request (or series of
requests, in the case of enumerations) is no longer a record on the MCU.
the next section. A client may periodically include the listAll Boolean parameter set to TRUE to
indicate that the MCU should return every record available. Enumeration limits still apply so multiple
calls using the standard enumeration protocol may be required. This allows a client to resynchronize
to the MCU, because it can safely assume that any record not returned by this request (or series of
requests, in the case of enumerations) is no longer a record on the MCU.
For example, any participants not returned by participant.enumerate when listAll is set to true can be
assumed to have been removed from the MCU.
assumed to have been removed from the MCU.
The listAll parameter can still be used in conjunction with the lastRevision parameter: doing so means
that every record will be returned, but records that have not changed since the specified revision may
have many members removed from their substructures. Substructures that have had members
removed in this way will contain a field named “changed” instead, which will be set to false indicating
that there are no changes to the data in this substructure since the specified revision number.
that every record will be returned, but records that have not changed since the specified revision may
have many members removed from their substructures. Substructures that have had members
removed in this way will contain a field named “changed” instead, which will be set to false indicating
that there are no changes to the data in this substructure since the specified revision number.
Dead records
The second approach to the record removal problem is the dead parameter. The MCU will maintain a
cache of records that have been removed and are in no sense considered active; a “dead” record will
never be returned if revision numbers are not being used or if the listAll parameter is set to true (e.g. a
previous participant record is still not considered a dead record because it would be returned by a
normal participant.enumerate request).
cache of records that have been removed and are in no sense considered active; a “dead” record will
never be returned if revision numbers are not being used or if the listAll parameter is set to true (e.g. a
previous participant record is still not considered a dead record because it would be returned by a
normal participant.enumerate request).
A dead record will be returned by a call supporting revision numbers if the lastRevision parameter
designates a revision at which the record was not yet dead. The returned record will contain only the
fields necessary for its identification and an extra field “dead”, which will be set to true to indicate that
this record should no longer be considered to be present on the MCU.
designates a revision at which the record was not yet dead. The returned record will contain only the
fields necessary for its identification and an extra field “dead”, which will be set to true to indicate that
this record should no longer be considered to be present on the MCU.
These dead records are only cached on the MCU for a few minutes; therefore a client should not rely
on them unless it is doing very regular polling. When using less frequent polling using the listAll
parameter described above is more appropriate.
on them unless it is doing very regular polling. When using less frequent polling using the listAll
parameter described above is more appropriate.