STDIO plugins or how to combine incompatible
The idea is simple - we connect an external module to the program through a pipe (STDIO or TCP / IP).
Text command exchange in command line format: <command> [parameter [parameter [...]]] <CR / LF>
The parameters can be any serialized data. As in the POP3 / SMTP protocols.
Thus, you can connect to the program, for example, a syntax check or a translator, which really is somewhere on the Internet. You can connect plug-ins written in any scripting languages ​​(batch file, for example) and platforms. You can even connect the program to itself. =)
The whole point is to use the APIs as an API for plugins (instead of directly calling code), and not for filters. The idea is not new, but for some reason very rarely used.
Another advantage - the fall of such a "plug-in" does not affect the operation of the program. Plug-ins can work in separate tasks or on separate machines, you can easily build multi-tasking computing clouds.
')
I tried to implement this - it turned out. True, there are some difficulties in the work of STDIO under Windows. For example, uncontrolled buffering, when a plugin “caches” its output into the buffer and returns it only when the buffer is full or when the channel is closed. I have not fully studied the nature of this phenomenon, but if the plugin does flush buffers for each team, then everything works as it should.
Another problem is that working plugins clog up the process list. Although, perhaps this is a plus ... =)
The speed of work is quite decent; in the era of “pocket gigaflops” and total dominance of XML, the cost of parsing a string with spaces is negligible.
Text command exchange in command line format: <command> [parameter [parameter [...]]] <CR / LF>
The parameters can be any serialized data. As in the POP3 / SMTP protocols.
Thus, you can connect to the program, for example, a syntax check or a translator, which really is somewhere on the Internet. You can connect plug-ins written in any scripting languages ​​(batch file, for example) and platforms. You can even connect the program to itself. =)
The whole point is to use the APIs as an API for plugins (instead of directly calling code), and not for filters. The idea is not new, but for some reason very rarely used.
Another advantage - the fall of such a "plug-in" does not affect the operation of the program. Plug-ins can work in separate tasks or on separate machines, you can easily build multi-tasking computing clouds.
')
I tried to implement this - it turned out. True, there are some difficulties in the work of STDIO under Windows. For example, uncontrolled buffering, when a plugin “caches” its output into the buffer and returns it only when the buffer is full or when the channel is closed. I have not fully studied the nature of this phenomenon, but if the plugin does flush buffers for each team, then everything works as it should.
Another problem is that working plugins clog up the process list. Although, perhaps this is a plus ... =)
The speed of work is quite decent; in the era of “pocket gigaflops” and total dominance of XML, the cost of parsing a string with spaces is negligible.
Source: https://habr.com/ru/post/83756/
All Articles