earl
earl copied to clipboard
Service Objects for Crystal (Agents, Artists, Supervisors, Pools, ...)
On exit, Earl::Application calls terminate on all agents in the supervision tree, but does not wait for them to transition from stopping to stopped or crashed state. This leaves no...
If reset on an Agent isn't explicitly overridden, it might be better to assume that the agent cannot be reset, instead of doing nothing.
Right now `Mailbox(M)` merely delegates to `Channel(M)` which only permits unidirectional communication from an actor A to an actor B, but doesn't permit B to reply to A after it...
This example fails to compile with `Error: method Bar#call(AbstractMessage) must be defined`: ```crystal require "earl/artist" abstract struct AbstractMessage end record FooMessage < AbstractMessage module Foo macro included include Earl::Artist(AbstractMessage) end...
The Erlang `gen_server` behavior allows to abstract the communication with an actor, by providing a public API that sends messages to the actor (from the outside actors) and have distinct...
The current `Registry` actor is poorly named. It's purpose is to broadcast the messages it receives to all subscribed listeners. There is no selection of what listeners will receive, so...
Mailboxes no longer inherit from `Channel(M)` but use a tailored solution for agent mailboxes that's simpler and with less overall allocations (thanks to `Syn::Core`). **Kept as DRAFT because:** - This...
An agent's state may be changed by whatever fiber is calling an action on the agent (e.g. call `#stop`). The state machine only allows state to transition from one state...
`Registry` should be re-purposed to become a named registry of agents. Agents would be able to register themselves with an unique name across the application. Supervisors might be able do...
Earl::Scheduler should be properly documented. A brief example in the `README.md` as well as an extended documentation in `SPEC.md`. Related to #11