Re: review of ldp-paging

Sandro, what behavior did you have in mind if we added your unless clause?
As you can tell from my response (if you squint a bit), I read your intent 
to be "if the container is sorted, the server is [probably: has to] add a 
page anywhere in the sequence [in order to maintain the sorting constraint 
it advertised], or to 410 the sequence" and it's the first part that my 
response was concerned with.  If you had in mind that the server Must 
abandon the sequence if it adds a page other than at the end, that's not 
nearly as problematic for clients.

> > 4. adding at the end
> > pages to the end.  Can we add, "unless some other ordering is 
signalled, 
> 
> I never read 4's topic to be connected to sorting - ever, at all; 
> completely orthogonal concerns in my mind.  I thought the point of 
> the constraint on adding pages was to give the client a predictable 
> way to detect if more pages had been added (keep re-fetching last 
> page known to it and looking for either 4xx or link rel='next' to 
> show up in the response). 
> 
> I agree that makes adding pages into a server-sorted container 
> potentially impossible (in the sense of doing so by adding the 
> rel=next link), but I took that effective constraint as simply a 
> consequence of the functional composition.  If you relax the 
> constraint for sorted containers, for those you're rendering 4's 
> constraint useless; either way you're saying, in effect, that they 
> don't play nice together.  Given that the result is the same, I'm 
> pretty agnostic as to whether we treat that as a "club the baby 
> seal" moment or not.  The more pages in the sequence, the less that 
> allowing pages to be added anywhere helps a client, AFAICS; instead 
> of re-fetching 1 page the client would have to re-fetch all pages in
> order to 'poll' for new ones, which is not meaningfully different 
> from traversing anew. 



Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead