February 10, 2010 at 16:54STDIO 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).
Exchange of text commands in command line format: <command> [parameter [parameter [...]]]
The parameters can be any serialized data. As in the POP3 / SMTP protocols.
Thus, you can connect to the program, for example, syntax checking or a translator that is actually located somewhere on the Internet. You can connect plugins written in any scripting languages (batch files, for example) and platforms. You can even connect the program to itself. =)
The whole nuance is to use pipes as an API for plugins (instead of directly calling the code), and not for filters. The idea is far from new, but for some reason it is very rarely used.
Another plus is the fall of such a “plug-in” does not affect the program. Plugins can work in separate tasks or on separate machines, you can easily build multi-tasking computing clouds.
I tried to implement this - it worked. True, there are some difficulties in working with STDIO under Windows. For example, uncontrolled buffering, when a plugin "caches" its output to a buffer and gives 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 command, then everything works as it should.
Another problem is that working plugins clog the list of processes. Although, perhaps this is a plus ... =)
The speed of work is quite decent, in the era of "pocket gigaflops" and the total dominance of XML, the cost of parsing strings with spaces is negligible.
Exchange of text commands in command line format: <command> [parameter [parameter [...]]]
The parameters can be any serialized data. As in the POP3 / SMTP protocols.
Thus, you can connect to the program, for example, syntax checking or a translator that is actually located somewhere on the Internet. You can connect plugins written in any scripting languages (batch files, for example) and platforms. You can even connect the program to itself. =)
The whole nuance is to use pipes as an API for plugins (instead of directly calling the code), and not for filters. The idea is far from new, but for some reason it is very rarely used.
Another plus is the fall of such a “plug-in” does not affect the program. Plugins can work in separate tasks or on separate machines, you can easily build multi-tasking computing clouds.
I tried to implement this - it worked. True, there are some difficulties in working with STDIO under Windows. For example, uncontrolled buffering, when a plugin "caches" its output to a buffer and gives 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 command, then everything works as it should.
Another problem is that working plugins clog the list of processes. Although, perhaps this is a plus ... =)
The speed of work is quite decent, in the era of "pocket gigaflops" and the total dominance of XML, the cost of parsing strings with spaces is negligible.