Supervisor implementation feedback!

[wind grail]

Hi! I'm bumping the version of otp of my library eventsourcing with a new PR. Can anyone with experience with OTP give feedback on the implementation of the new_supervised function? And how would you test such function?

[rocky prairie]

hah, testing similar thing. qant to see the child die and be restarted

[last walrus]

I once made a ruby event sourcing lib with actors for the sake of it. I should port it to gleam 😄

[rocky prairie]

a test-event handler can be told to die in various ways, tho.

confuswd. shouldn't the new_supervised return a static_supervisor.supervised instead of start, so it can be hooked into a larger supervisor structure of appa using your lib?

which brings you to the same problem i ran into, how to get to your actor. answer: named process and named subject. Have not heard of other ways in gleam, yet.

[wind grail]

That makes more sense thank you!

[ancient fable]

The convention is for it to be called “supervised”, not “new_supervised”

It’s also not returning a child specification so it can’t be supervised

I think, the annotations are missing so it’s hard to read

[wind grail]

Makes sense oki

[wind grail]

Now it should be fixed, the function has been renamed to supervised and now returns a tuple of specifications!

[random echo]

This isn't the simplest example, as it tests things end-to-end, but here's how I tested the supervised version of my MQTT client: https://github.com/sbergen/spoke/blob/main/spoke_integration_tests_erlang/test/supervision_test.gleam

Essentially, it sets up the supervision tree and triggers for "stuff to happen" when the child starts, then I wait for the child to be started, kill the supervised child, and assert that things happen again when it restarts.

[paper notch]

@random echo Your MQTT library looks very cool. For context: I'm a gleam/erlang newbie. I'm studying various code/repos to learn more about supervision trees and subjects and such. Comparing your spoke library and @opaque zinc 's glisten gleam tcp library... I'm curious. Was there something about glisten that didn't work for you? I ask b/c it seems like theer's a fair bit of overlap between both libraries.

[random echo]

My concrete motivation to write spoke was to use it in my custom home automation system (which I originally wrote in Rust), which uses MQTT (zigbee2mqtt being a big part of it). Spoke itself is transport channel agnostic implementation of the client side of the MQTT protocol, so it doesn't really have overlap with glisten. I do test the TCP transport channel implementation using glisten, though! This is gettin a bit off topic though, so if you have more questions we could probably move the discussion here: #1330172914229706813 message