Re: [netconf] restconf collections

[Kent Watsen <[e-mail]>]

Hi Robert,

> It's been quite some time since I did lawyer-reading the RFCs, but for
> the sake of argument:
> 
> - is use of hash maps for keyed lists okay, hence the sort order is the
> encounter order based on the contents?
> - if so, does that order remain the same even across server restarts?
> 
> I am not sure what the litmus test for 'reasonable' would look like, I
> am afraid.

Perhaps it’s derived from the next sentence:

	The "description" string for the list may suggest an order
	to the server implementor.

This suggests that the intention is that servers should be able to at least *return* a stable order.   How a server achieves this (given its DB-backend, etc.) is implementation-specific.  


> If the requirement is to really just have an iterator, which breaks when
> the list changes, then a node-tag+offset would be sufficient. But then
> you could end up in a situation where you will never traverse the list
> simply because its rate of change exceeds your ability to traverse it.
> 
> The path forks quite a bit if you want something more specific, like:
> "visit all elements in any order, i.e. additions do not break iteration".
> 
> If we have requirements towards that level of complexity, then yes, I
> would very much prefer if there was a cursor-like resource associated
> with an ongoing pagination request.

Ack.

And the tradeoffs aren’t even just "easy/potentially-imperfect" vs. "hard/perfect", as resources come into play, and the scales tip after a number of successive calls.

FWIW, for CT-queries, RESTCONF's Etag/Last-Modified tags can be used to catch a potential imperfect response.


> If I squint just a little bit, the first paginated request is not that
> different for a (one-shot) subscription to receive notification of all
> list entries. Subsequent requests are fetches from that notification
> stream... which shows my reactive systems bias :)

Yes, streaming is goodness, but there’s generally a need for the most-recent to be on-box also.  That said, we could conclude that streaming SHOULD be used to export very-fast logs and therefore easy/potentially-imperfect is “good enough” for queries.

Streaming only applies the CF lists holding time-series data (e.g., logs), which is an important part, but not the only part, being discussed.  Maybe different “requirements”, as you say, apply to CF vs CT lists?

K.