How to expose/organize <daemon>d
entryoints?
#488
Labels
data-layer
real-time and historical data processing and storage
factoring
less codez dawg
question
wut dis!?
services
daemon (actor runtime) related design and supervision
(sub-)systems
general sw design and eng
As per the reorg in #483 I think it's worth replacing all the daemon entry points currently defined in
piker.service._daemon
to possibly submods in each sub-system/package.As an example, for the data layer, we could move
maybe_spawn_brokerd()
andspawn_brokerd()
into apiker.data._daemon
(though we probably want to move this particular daemon asdatad
once we split broker vs. rt feed tasks into separate actors).The idea being that each sub-sys defines it's own "endpoints" for different services that can be started by name from the
.service._mngr.Services
API?I feel like this would make it clear which systems can be run on separate hosts as well as how execution workloads are generally separated logically in our code base?
Another thing i've been groking is whether we should move our
Qt
integration viatrio
-guestmode in.ui._exec
maybe into a.ui._daemon
as well since eventually we want to be able to spawn UI actors underpikerd
such they are supervised in the same was services and don't require a diff root actor for supervision/respawn?Main issue for this support in
tractor
: goodboy/tractor#281The text was updated successfully, but these errors were encountered: