5 ms·
Surely a lot of that could be done with a commandline switch? tape_robot start -tapeid=1 as the quick hacky version, and: tape_robot --protobuf 'msg:
by deckiedan 11y ago
Surely a lot of that could be done with a commandline switch?
tape_robot start -tapeid=1
as the quick hacky version, and:
tape_robot --protobuf 'msg:start;tapeid:1'
(replace the 'single:quote;string:thing' with your protobuf message.), or
tape_robot --protobuf_file filename
The filename could be a fifo or socket, of course. Then use a general purpose server which runs the programs:
proto_serve tape_robot 127.0.0.1:8080
or whatever.
This (to me) is closer to the unix idea - one server program, one actual processing app. Why should my tape_robot program actually have a server embedded in it?
If in the future, I want to add authentication, I only have to add it (once) to the proto_serve program, rather than to every single application that is a 'server', for instance.
It would also allow a version which 'pre-forked' the processes, and left them waiting for the data on the socket/filehandle, or whatever.
You could do a bunch of this already using nc or similar, I suspect.
- sanderjd 11y agoInteresting. This seems very non-unix-y to me. The `tape_robot` doesn't "do one thing", it does many things, including parsing protobuf from shell strings and files, which seems error prone and way outside its core competency.
- deckiedan 11y agoMaybe I misunderstood @jalfresi's idea - as I understood it, it was that each command would do not only parse protobuf and unix style flags, but also contain a RPC server of some sort. My reinterpretation was to say how about factoring out the server part, and leave the command only understanding either flags or protobuf commands - which could be delivered to the command either as an arg, or as a file given to it by an arg. You could go a stage further by having all commands only accept protobuf (or similar), and distribute a spec/human-mapping to go with it. Then your shell would parse the args that you give to the command using the spec, and actually call the command using protobuf. This would allow very awesome shell completion / highlighting / etc. It should also allow much simpler end-point/commands, as they'd not have to do hardly any type checking / re-parsing, as it would arrive in protobuf. I actually kind of like that idea. Hmm...
- sanderjd 11y agoThis is actually a step toward how PowerShell (is it still called that?) works, where you pipe objects (ie. a schema) around instead of arbitrary strings.