I think "Counting the number of request" necessary to do something is a good idea to get an idea if things work.
-
I think "Counting the number of request" necessary to do something is a good idea to get an idea if things work. It is like the infamous back of the envelope calculation from physics. It's a quick method to get an idea what is going on. Often the answers are correct.
As an example, due to me reading about it again, that ActivityPub Client To Server as specified. In order to see if there is new content you need to make a request. So if you want to update the content of your client every 10 seconds, you are making 6 requests per minute. If you use technology such as websockets, you are left with 1 request total.
-
@helge one long running request which is arguably harder to scale and has its own issues...
-
infinite love β΄³replied to Emelia πΈπ» last edited by
@thisismissem @helge http sse (server sent events) might work here? assuming http/2 support
-
Emelia πΈπ»replied to infinite love β΄³ last edited by
-
@thisismissem @trwnh @helge So back when I was working on a client for pump.io a decade I just did a sync every N minutes (default 30!) and it was fine. Also opening your app feed would do a refresh, and we had pull to refresh
So its important to remember that with aspects like this the idea (sort of) was βthis is experimentally sufficient, and there are reasonably obvious extensions hereβ
-
@thisismissem @helge @trwnh Extending the inbox to support something like server sent events is not too complicated, the one thing is you might need to reify how cursors work into the protocol so people can switch form pagination to SSE