@sschu just wanted capture some of what I was trying to convey in the meeting and some points that were mentioned in earlier design docs. Please add what you have, and I'll add some more about using a continuation token.

Additional Considerations:

• For all resources which will not have an excessive number of entries (possibly everything except for users) we don't need to offer sort and slice features. Instead admin api clients via projection would obtain the indentifier fields and any sorting columns, perform their own client-side sort, then fetch whatever pages they want by identifier. We could add support for bulk fetching by id to cut down on the number of api queries.

• For resources with an excessive number of entries, or for which we do want to offer sorting / slicing:

  • Federated (such as users): we should avoid supporting server side sorts that would need to be either in-memory or performed as a multi-pass sort using disk space. This would imply any sort support would need to be based upon partitioning.
  • Non-federated: Standard sort and slice mechanisms could apply - but there is still an issue on push-down of sorts. Some projected fields may be computed, and the desired sort order could be based upon a particular charset.
  • Websockets are an alternative for scrolling a large number of results (see https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/3157-watch-list)

• Skipping pages isn't strictly necessary, but is a nice to have feature.

cc @mabartos @vmuzikar