The other things is collection filtering. This is where you check each item in a page to see if the client can actually read it, and leaving it out if not. It's very important if you include embedded objects, and not that important if not. If you only include references, they can be checked when the client tries to fetch them.

Another thing is whether "pages" in your collection are real objects -- buckets that fill up with items as time goes on -- or just fixed-length offsets from the most recent item. I think having real pages is much better for caching and synchronization.

Anyway, here's my thought: I think the advantages of embedded objects are offset by the problems with caching. I think we should make collection pages real, stable objects, with fixed contents and real modification dates. Return only references, not embedded objects. Do filtering, though. And make pages big -- 100 items or more.

@macgirvin the 12-item page size is a real kick in the teeth.

@evan@cosocial.ca remind me to change pagination size to 1 on April 1st

@macgirvin oh, but: I disagree about configurable page sizes. I think pages should have stable contents, have last-modified dates, and be easily cacheable. It makes traversal and synchronization much better.

@julian you monster

@macgirvin like, only the most recent page should be volatile. Except for deletions, older pages should not change.

@evan@cosocial.ca in reverse chron every page changes when a new item is pushed to the stack.

Even in chronological sets if you need to account for deletions you've basically given up already because there's no immutability guarantee! This is why caching headers exist, no?

@julian that's the way to do reverse chron that messes with caches!

Instead, number your pages from oldest to newest. So page 1 was the first page created. After PAGE_SIZE items have been added, create page 2, make it the `first` page, and now page 1 never changes (unless one of its items gets `Remove`d). All your volatility is in the most recent page, and older pages rarely change.

You can also use UUIDs or other IDs for pages.

@julian the downside is that your `first` page is rarely full. You can get around this by having the `first` page be up to 2 * PAGE_SIZE in length, and shifting PAGE_SIZE items to a new page when the `first` page hits its max.

@evan also http/3 which is widely used currently, has multiplexing, so making multiple requests does not come with a penality anymore (if the objects are on the same host)

@evan mastodon’s approaches is interesting in this regard, it returns embedded objects for local items, and references for remote objects. Best of both

@django it's good in some ways, but they still don't return Last-Modified headers.