Julien Portalier

Crystal already provides a log handler that can be used: https://github.com/crystal-lang/crystal/blob/master/src/http/server/handlers/log_handler.cr

Yes, something as simple as: ``` crystal log_handler = HTTP::LogHandler.new(STDOUT) HTTP::Server.new("::1", 9292, [log_handler]) { |ctx| MyApp.call(ctx) }.listen ``` I think that whatever can be implemented as a Handler should be...

No. Crystal still generates a `main` method: https://github.com/crystal-lang/crystal/blob/7eae5aa3ccd0fbfef1b048fa31ae644b571cb11e/src/crystal/main.cr#L132

What changed is that it's now easier to redefine the `main` method, but it's always generated.

Yes, exiting is still bad. Alternatively, Supervisor and Pool could prevent the agents they spawn to outlive them? With Application eventually exiting anyway after a graceful time —or a second...

I assumed that agents didn't need to reset something when they're recycled. This applies to most of the design: have noop methods that can be overridden if needed —except `call`...

Agents don't *need* to be supervised, so an abstract `#reset` feels too drastic. Looking at a real application using Earl I have, only 1 out of the 4 agent types...

Earl relies on direct method calls on actor objects for simpleness. In this case `actor.send(msg)`. We could add an optional argument pass an actor as a second parameter, that is...

Among possibilities, the send paradigm could be changed. Instead of calling `#send` on the destination we'd call `#send` on the current actor, passing the destination actor as an argument. That...

Aparte: Crystal doesn't implement matchers to deconstruct tuples, so we can't use something like the following as a 4th alternative to the receiver dilemma, it would be as bothersome as...