Actually, I wasn't thinking straight.... The cutoffEvent is not at all related to lastEvent property I'm suggesting. The lastEvent property is needed whenever a client is polling periodically, so that it can know if it is useful to poll the log again or get a new snapshot. Clients need to remember the last event they processed, and that is what they need to compare with the lastEvent property in each page of the log to ensure that they don't need to get another base snapshot. The cutoffEvent property is only used to when polling the change log the first time.
================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 From: Joe Ross/Austin/IBM To: [email protected], Date: 05/02/2013 01:08 PM Subject: TRS truncation of change log 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
