One regret I have about ActivityPub is that navigating reverse chronological collections is really error-prone.
Technical Discussion
5
Posts
3
Posters
0
Views
-
One regret I have about ActivityPub is that navigating reverse chronological collections is really error-prone. "first", "last", "next" and "prev" mean the opposite of what you think they mean, so it's easy to get mixed up and navigate things the wrong way.
It's too late to change now, but I could see adding some synonyms for these properties, like "newest", "oldest", "older" and "newer", to make it easier to do the navigation code.
-
One regret I have about ActivityPub is that navigating reverse chronological collections is really error-prone. "first", "last", "next" and "prev" mean the opposite of what you think they mean, so it's easy to get mixed up and navigate things the wrong way.
It's too late to change now, but I could see adding some synonyms for these properties, like "newest", "oldest", "older" and "newer", to make it easier to do the navigation code.
@evan could this be fixed by a future version? Or given that the set is not overlapping I guess they could be provided concurrently for compatibility?
-
undefined julian shared this topic
-
One regret I have about ActivityPub is that navigating reverse chronological collections is really error-prone. "first", "last", "next" and "prev" mean the opposite of what you think they mean, so it's easy to get mixed up and navigate things the wrong way.
It's too late to change now, but I could see adding some synonyms for these properties, like "newest", "oldest", "older" and "newer", to make it easier to do the navigation code.
evan@cosocial.ca what about
after? Using paginated collections is easy, but could be problematic if the set changes while you are navigating.Using
afteris a little more complicated but much more reliable in terms of getting exactly the next set of items. -
@julian Pages should be real containers, not slices of the collection like "last 25 items".
-
System shared this topic
-
@evan could this be fixed by a future version? Or given that the set is not overlapping I guess they could be provided concurrently for compatibility?
@flancian It's an egregiously backwards-incompatible change, so probably no.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
-
I've been thinking lately about flow control. That's a feature of some networks where a receiver can tell a sender to slow down its sending rate to match the receiver's processing rate.
In TCP flow control, the receiving host returns a receiving buffer size in its acknowledgement segment, so the sending host know how much data it can send without overflowing the buffer.
I wonder if there are ways that a receiving ActivityPub protocol server could tell the sending server to slow down? Maybe we could reuse some of the RateLimit headers.
Another option would be a special header that says how big your incoming activity queue is. "I have a very long processing queue right now, please keep stuff in your outgoing queue for a while."
-
@flancian It's an egregiously backwards-incompatible change, so probably no.
-
@julian Pages should be real containers, not slices of the collection like "last 25 items".
-
evan@cosocial.ca what about after? Using paginated collections is easy, but could be problematic if the set changes while you are navigating.
Using after is a little more complicated but much more reliable in terms of getting exactly the next set of items.
-
@evan could this be fixed by a future version? Or given that the set is not overlapping I guess they could be provided concurrently for compatibility?
-
One regret I have about ActivityPub is that navigating reverse chronological collections is really error-prone. "first", "last", "next" and "prev" mean the opposite of what you think they mean, so it's easy to get mixed up and navigate things the wrong way.
It's too late to change now, but I could see adding some synonyms for these properties, like "newest", "oldest", "older" and "newer", to make it easier to do the navigation code.
-
@thisismissem@activitypub.space Ah, I seem to have misread the code. I was confused by Mastodon serving its own instance actor from /actor. Thanks for the clarification!
