Proposal: bi-directional stdin/stdout communication interface

[prusnak]

Currently the communication with HWI goes like this:

exec hwi enumerate
read from stdout [ list of devices in json ]

exec hwi -t device command arguments
read from stdout ... json response ...

While this might be a better match:

exec hwi enumerate
read from stdout [ list of devices in json ]

exec hwi -t device connect
write to stdin { "command" : "command1", "args": { "arg1": "...", "arg2" : "...", ... } }
read from stdout { json response }
write to stdin { "command" : "command2", "args": { "arg1": "...", "arg2" : "...", ... } }
read from stdout { json another response }

Or even:

exec hwi
write to stdin { "command": "enumerate" }
read from stdout [ list of devices in json ]
write to stdin { "command" : "command1", "args": { "arg1": "...", "arg2" : "...", ... } }
read from stdout { json response }
write to stdin { "command" : "command2", "args": { "arg1": "...", "arg2" : "...", ... } }
read from stdout { json another response }

This would enable us to add so badly needed sessions into HWI and these sessions will exist only on memory, so we don't need to ponder how to store them on the filesystem. Having this would allow us to fix issues #326 or #447 easily without any hacks.

[achow101]

We have an --interactive switch where this could be implemented.

However I dislike the idea of having HWI be a pseudo-shell like that. For downstream consumers, they have to spawn another thread just to keep HWI running and then communicate with it asynchronously and that is kind of annoying to do. Perhaps @molnard, @nopara73, and @NicolasDorier could pitch in with what they would prefer?

[NicolasDorier]

well on my side we just use the program with proper args and read the output. This is good enough for what we want to do, so I don't expect changing this.

[molnard]

I prefer the current design. If it is possible to solve this by adding a new parameter to the call like a "session key", that would be an optimal solution.
#326 (comment)