Hello Nick,
Thank you for such an extensive investigation and detailed examples! I apologise for my late feedback. I tried to reduce it to the points that can be voted on:
- I suggest we make error handling related to rebasing normative and non-optional (i.e. no MAYs). E.g. “if the rebase
was carried out and the server does not support reading older change logs, the server SHOULD return a 410 Gone HTTP error for a client request to read a stale change log page, but MAY use another 4XX code”. This is in line with your example from p.12, which
says that the server must either return an expected fifth page or fail.
- I think that the requirement on p.14 is too harsh for the TRS Server implementations and would push them to use order-based
query strings as shown on p.15, which I don’t like (hard to cache + may be abused by developers who would try to construct it programmatically). I think it’s okay to allow the events seen on page n to be seen on page n+1.
- We might suggest non-normatively that if such duplication is observed, a client is recommended to reduce its polling
period.
- I agree with the proposal on sl. 16. I would, however, suggest the following RFC keywords:
- a TRS resource itself SHOULD have an ETag
- because we intend the TRS resource to be polled every 10 seconds or so. SHOULD can still be ignored,
but that should be an exception rather than a norm.
- a server SHOULD respond 304 Not Modified if there are no changes in the TRS…
- because MUST could be tricky to implement if the developers want to rely on the HTTP server to provide
this functionality and not to code it themselves. In other words, I return a TRS resource and set its Cache-Control: max-age=15 (seconds). Varnish/Nginx/Apache can automatically calculate its ETag, and handle If-* requests for the next 15 seconds. But after
15 seconds a TRS Client might get a 200 OK if the RDF serialisation was not stable (it does not have to) even if no events have occurred since.
/Andrew
P.S. I will soon post a proposal on the lyo-dev list for a new paging scheme for Lyo’s TRS Server and you are welcome to provide feedback.
Here is the note covering TRS spec and design issues. I'll give a brief intro and overview in today's meeting, but I expect you will each need some time to review the document.
Nick.
|