Howdy! Christopher Allan Webber <cweb...@dustycloud.org> skribis:
> Ludovic Courtès writes: [...] >> It’s also a situation where adding the config file to /etc would be >> reasonable (until Shepherd actions can actually be added :-)). > > True. Though we still run, potentially, into problems where multiple > instances of some service are provided, eg multiple mediagoblin servers > or mail daemons or etc. Sure, definitely. All I meant was that populating /etc can be done as a quick stop-gap measure when it makes sense, but it’s not a great solution, notably because of the multiple-instance problem you describe. > Note: I'm interested still in exploring the shepherd actions stuff > still... though I did realize this morning that it wouldn't help in the > rare commands that have interactive input... there's no way to send > input/output in that way through the herd afaict! Oh well, that's > probably pretty rare. > > Speaking of I/O from commands, I wonder how you'd give any kind of > output back through an action to the herd? Afaict the protocol supports > it and allows sending back "messages" that will be displayed, but > nothing uses it yet. There's a <command-reply> record type that afaict > nothing uses at all. <command-reply> is used for every reply sent by the daemon, in (shepherd). However, this hasn’t been thought to provide interactive commands and such things; I’m not sure it would be a great idea to support interactive commands, dunno. The protocol currently is just: you connect, you send a request, you get a reply, and you disconnect. Actions are expected to be non-blocking. Ludo’.