The plugin architecture here reminds me of what happened with VS Code - once you give users a proper JavaScript API and decent documentation, the community starts solving problems you never even knew existed. But there's something particularly clever about IINA's approach: they're essentially turning every media file into a potential canvas for interactive experiences.
I had a coworker introduce me to The Five Dysfunctions of a Team[0] as a useful tool for framing problems with team dynamics.
It's easy to draw parallels between what's described and those dysfunctions. In case you're not familiar, this framework by Patrick Lencioni outlines five obstacles that can mess up a team’s flow: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results.
Particularly relevant to this situation:
> Fear of conflict: seeking artificial harmony over constructive passionate debate
Just to warn you though, there is a tradeoff. You can also just act like an asshole and cite a culture of toxic positivity if people take issue with your behavior. The key is collaborate, productive focus on the outcomes with the other human beings involved in the endeavor.
Yeah, I think this was more inward focusing on things like `Oban` in elixir land.
He's made the distinction in the article that those tools are great when you need durability, but this gives you a lower ceremony way to make it Just Work™ when all you're after is passing off the work.
Ah, that makes a lot of sense - I think the FLAME.Parent{} approach may enable backends that wouldn't be possible otherwise.
For example, if I used the heroku api to do the equivalent of ps:scale to boot up more nodes - those new nodes (dynos in heroku parlance) could see what kind of pool members they are. I don't think there is a way to do dyno specific env vars - they apply at the app level.
If anyone tries to do a Heroku backend before I do, an alternative might be to use distinct process types in the Procfile for each named pool and ps:scale those to 0 or more.
Also, might need something like Supabase's libcluster_postgres[1] to fully pull it off.
EDIT2: So the heroku backend would be a challenge. You'd maybe have to use something like the formation api[2] to spawn the pool, but even then you can't idle them down because Heroku will try to start them back. I.e. there's no `restart: false` from what I can tell from the docs or you could use the dyno api[3] with a timeout set up front (no idle awareness)
So, Chris, how do you envision the FLAME child understanding what OTP children it needs to start on boot, because this could be FLAME.call dependent if you have multiple types of calls as described above. Is there a way to pass along that data or for it to be pulled from the parent?
Acknowledging this is brand new; just curious what your thinking is.
EDIT: Would it go in the pool config, and a runner as a member of the pool has access to that?
Well, that was 8 hours ago - you get anywhere noodling over this?
I'm trying to go through the same thought process - this is neat, how do i translate into more practical applications. It seems like such a powerful paradigm if one can figure out that mapping.
Yeah, you can't - but you're also not supposed to be snarky ;)
> Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.
That being said, usually repost happen with substantially new information, perhaps OP should post what's new or what warrants the repost.
Yeah, i think given the license to do 'whatever' they can also be powerful 'problem finders' - that is, discovering opportunities for major level ups that no one else is currently seeing.