busybee fluffy rambles

asyncio generally requires that you provide a “session”/“client” object that contains the run loop for the async operations. I think that when you refactor a library to support asyncio, you provide a non-async wrapper around it which spins up the execution loop for each operation, although there might be a better pattern for it these days.

An antipattern I’ve seen a lot is people wrapping a non-async library in a threadpool and then have the async wrapper block on the future, but that completely misses the point to asyncio and makes everything perform way worse.

asyncio is kind of wonky to wrap your head around at first but it’s well worth it for the major performance gains you get. It can be a huge pill to swallow though, and given that most Python web apps are still running in a thread-per-connection context (because wsgi is designed around it) it can feel like a chicken-egg scenario at times. But doing the work of moving to asyncio (and providing a non-async wrapper around it) makes it easier for more things to move to asyncio and getting the performance benefits as a result, so it’s a net good IMO, even if it isn’t heavily used right away.

Indieweb Utils looks pretty neat and there’s a few projects I’ve had on the backburner which would benefit from this.

I’d also be pretty tempted to look into moving Pushl over to it, just to cut down on my own code maintenance requirements, except it looks like it doesn’t have any support for asyncio, which is less-than-optimal for an I/O-bound tool which sends a bunch of bulk updates. Is there any interest in adding asyncio support?

Song Fight! Live 2022 is a go, happening October 8 at 6 PM Pacific/9 PM Eastern on YouTube:

Some time later, my set alone will be available on my YouTube channel. Don’t forget to subscribe to my channel to keep the algorithm from eating your soul.

Yay, the big financial albatross is no longer around my neck. Now I can feel a lot more free to move forward with all of the projects I’ve been wanting to do, and not have to worry about, y'know, finances for a while.

I already feel a million pounds lighter.¹

So anyway, time to start looking at redoing my kitchen.

Back when the VRChat debacle took place, I’d rambled quite a lot about the idea of a standards-based truly-distributed VR system. I probably mentioned how back in the day I was designing something like that, and was intending to use XMPP as the actual transport mechanism; in my more recent reevaluation of the idea I was thinking that using WebRTC to stream the actual realtime data (voice, character animation, etc.) would be the way forward.

Well, the Matrix folks just announced Third Room, which is the same basic concept, running on Matrix and WebRTC! They’ve also made a bunch of other great technology choices along the way.

This is pretty exciting and I’m looking forward to seeing where it goes. At least from a 20,000-foot view it hits all of the right notes for me. For example, using glTF for all object interchange, focusing on in-world editing, and allowing for (apparently optional) world persistence.

Hopefully this can disrupt the stranglehold VRChat has on social VR and will also be a fun, compelling experience in its own right.