I’m looking at adding a local control capability to my little C++ based file and volume identifier tool. I’ve run into a number of small functions that would be well served by tools written in specific languages that have access to specialized APIs but would benefit from a local interface with somewhat decent performance.<\/p>\n\n\n\n
Unix style text in\/text out is limiting as the command\/response format lacks structure and the performance (with one process start per request) is potentially unacceptable.<\/p>\n\n\n\n
Adding in a command line switch that sets the tool into ‘json in\/json out’ mode and keeps the program alive until the pipes drop or an exit command is received should address these issues.<\/p>\n\n\n\n
Ideally, the stdin and stdout would transport UTF-8 data containing complete JSON entities…one as a request and one containing the complete response. This can continue until the hosting program sends an EOF or drops the pipes.<\/p>\n\n\n\n
I’m wrapping together a very lightweight JSON generator\/parser to support this effort and will be following that up with some testing of C++\/Java\/C# (and perhaps others) sub-process and pipe management coding. If all goes well, I should have a nice little approach for wrapping small pieces of code that need to run in a particular language but must be hosted elsewhere with decent performance and a robust communications format.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’m looking at adding a local control capability to my little C++ based file and volume identifier tool. I’ve run into a number of small functions that would be well served by tools written in specific languages that have access to specialized APIs but would benefit from a local interface with somewhat decent performance. Unix … Continue reading JSON over Stdin\/Stdout for small local components.<\/span>