Someone asked for this per e-mail, and it seems like a good idea.
Current open problems:
[x] Seemingly makes it impossible to stay runtime-agnostic
The only way to reliably wait on events e.g. on a channel seems to be using a runtime::spawn call. Also, we are currently using tokio broadcast channels. Maybe we could switch to smol?
Resolved: I've looked through the tokio discord and while there is no technical reason that means tower could not support other runtimes, it currently only officially supports tokio. The tower-http crate also depends on tokio, so I see no reason to stay runtime-agnostic at this time. If anyone reading this is interested in using this crate without the tokio runtime, please contact me.
[x] Decide if this should be feature-gated behind a default feature
Could make it possible for the crate to stay fully runtime-agnostic for people who do not need in-process reloading
Resolved: See first problem, runtime-agnosticism is no longer a goal. Feature gates can always be added later.
[x] Decide if every LiveReload should have a reloader
Probably fine, but bad if we want to feature-gate
Resolved: For now, every LiveReload has a reloader.
Someone asked for this per e-mail, and it seems like a good idea.
Current open problems:
runtime::spawncall. Also, we are currently using tokio broadcast channels. Maybe we could switch to smol?LiveReloadshould have a reloaderLiveReloadhas a reloader.