Re: [netconf] restconf collections

[Robert Varga <[e-mail]>]

On 30/09/2020 19:33, Kent Watsen wrote:
> Hi Robert,
> 
>> That is assuming the list in question has iteration order which is
>> stable. I do not believe this is something RFC7950 mandates on anything
>> except ordered-by=user.
> 
> If not “ordered-by user”, then its “ordered-by system” that, as RFC 7950 says, "the server is free to sort the list entries in any reasonable order.”  This is a stable ordering, IMO.

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.

>> So let's say the list has 4 elements A, B, C, D.
>>
>> 1) The first request returns items A, B, C.
>> 2) An item is inserted before C, so that the list is E, A, B, C, D.
>> 3) What does the second request return?
>>
>> Similarly:
>>
>> 1) The first request returns items A, B, C.
>> 2) An item is deleted before C, so that the list is B, C, D.
>> 3) What does the second request return?
>>
>> Pagination is deceptively hard.
> 
> Is your conjecture that the solution should enable something akin to cursors?  Would this be an advanced feature that a server might support on a list-by-list basis?   Maybe "node-tags” could be useful here too…

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.

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 :)

Regards,
Robert