Florian, Thank you for your explanation.
I'm implementing Atompub binding for getContentChanges for a CMIS server. I just want to get clarification if I need to have first, last and previous links in the changes feed. because CMIS specification mentioned them but I was still not clear how to implement them. With your explanation, it looks like I don't need to care too much about it, instead of only implementing the next link. Regards, Vincent ________________________________ From: Florian Müller <[email protected]> To: vincent tang <[email protected]> Cc: [email protected] Sent: Monday, October 27, 2014 6:42 PM Subject: Re: Paging in getContentChanges feed Hi Vincent, There is an intention behind the overlap. Repositories may clean out the change log from time to time because it is impossible for them to keep all change events from the beginning of time. If a client sees the overlap it knows that is hasn't skipped an event. If there is no overlap there were probably events that the clients never saw. For some clients that is an indicator to crawl the repository again. The first, last, and previous links only exist in the AtomPub binding. There is no equivalent in the other bindings. Only the next link is clearly defined. That's why you can't get to the other links from an OpenCMIS clients and that's why an OpenCMIS server doesn't generate those links. The semantics are undefined. Usually, that is not a problem. The change log tokens should be unique. Making the getContentChanges request with the same token should always return the same result (if the change log hasn't been reduced by the repository). Clients usually process each event once and then don't care about them anymore. Moving back and forth is not necessary (and not possible with the other bindings). What is your use case? Can you tell us why do you want to support the other links? - Florian > 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
