I have a question about paging getContentChanges. getContentChanges has only one paging parameter: maxItems while the other feeds has both maxItems and offset. However I think the spec means you can use changeLogToken as a mean as offset, because all change events returned by getContentChanges are ordered by the time they occurred. For example, if there are 16 change events in the change log, from 1 to 16. The request passes 1 as the changeLogToken and 10 as maxItems. The request URL may look like
http://hostname:port/cmis/resources/repo1/changes?changeLogToken=1&maxItems=10 The response will return 10 change events from 1 to 10 and 10 as the latestChangeLogToken. The next link of the feed will be http://hostname:port/cmis/resources/repo1/changes?changeLogToken=10&maxItems=10 The response will return 7 change events from 10 to 16 and 16 as the latestChangeLogToken. The next link of the feed will be http://hostname:port/cmis/resources/repo1/changes?changeLogToken=16&maxItems=10 Note that there is an overlap of change event #10. However the spec seems not to address it. Maybe it is allowed. This is not the main question in this email. My real question is: the spec mentioned that getContentChanges can have paging links like first, last, next and previous (both 1.0 and 1.1 spec). The example in v1.0 spec even have the 4 links. But if I understand correctly, first, last and previous seem not to mean anything. You cannot really get these links. Our CMIS server doesn't remember the changeLogTokens, we only know the current changeLogToken in the request and latestChangeLogToken in the response. The only paging link meaningful is next. I guess it is why the example in v1.1 spec has only next link. The application side should remember all the changeLogTokens if they want to get the previous 10 change events, the first 10 change events or the last 10 change events. We can generate first, last and previous links in other feed because offset is a numeric parameter. With maxItems we can always compute the first, last and previous offset, therefore we can generate first, last and previous paging links. But changeLogToken is an opaque string, I don't know there is any way to do it. It seems to be a question to the spec. Regards, Vincent
