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
