The Tracked Resource Set specification, states the following:
"To ensure that a new Client can always get started, the Change Log MUST contain the base cutoff event of the corresponding Base, and all Change Events more recent than it. Thus the Server is only allowed to truncate Change Events older than the base cutoff event. " However, since processing of the change log would happen some time after the base was read, it is possible that truncation happens between the time that a client reads the base and the time that it starts processing the change log. Truncation could also happen while a client is paging through the change log. In that case, it would be useful for a client to know about the truncation event before processing the entire change log, so that it can switch gears and obtain a new base snapshot instead. It seems that it might be useful if each page of the change log also included a lastEvent property. If at some point during change log processing, lastEvent becomes more recent than the cutoffEvent value that client knows, the client could then abandon change log processing and obtain a new base snapshot instead. Of course, we can add this property in our implementation, but seems it might be useful as an addition to the spec. ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311
