New stats for https://packages.sublimetext.io/

[deathaxe]

No description provided.

[FichteFoll]

If we're willing to change the interface further, We could also look into batching stat reports when multiple package operations are performed at the same time to save a few requests and bandwidth, since I imagine most updates to be performed on ST start.

[deathaxe]

Batching may certainly make sense as long as requests are sync. Not sure how important it will be with httpx sending requests via HTTP2 though. If those are just fired they should go through one connection one after another anyway without noticible delays. We don't need to wait for them to return tu continue installing next packages.

[kaste]

We don't have a bandwith/requests issue here at all. That would have been the case if we would store each event as a row/entry, and then do views/aggregates on the SQL and so on. With the current design of the db, that cannot be the case.

[deathaxe]

This request probably targets client side delays caused by sending pings synchronously. It may cause some delays when batch install/upgrade many packages.

[kaste]

Yeah, okay but that is almost unrelated to this PR as we do every possible side-effect always just when we feel for it. PC just doesn't group and orders side-effects and puts them at any boundaries.

[FichteFoll]

Batching the request was just a side idea I had that would also require changing the API and goes agains my preferred solution of simply making usage_url an array.

[deathaxe]

Array doesn't work as both end points use differend parameter names as well as response bodies. However I actually don't care about it being an array or not as the old one will be dropped as soon as packages.sublimetext.io matured enough.