chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vincent tang <vincentt...@yahoo.com.INVALID>
Subject Re: Paging in getContentChanges feed
Date Wed, 29 Oct 2014 16:01:07 GMT
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 <fmui@apache.org>
To: vincent tang <vincentt126@yahoo.com> 
Cc: dev@chemistry.apache.org 
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message