> OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren't very well defined (any proc

> OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren't very well defined (any process could describe its type of object). That's why we have IDL -- interface description language for RPC calls. An IDL-to-X (usually C) compiler generates the necessary glue so that anybody can talk to the program in question. IDL is also the basis of MS COM, which I quite like from the design standpoint. > The usefullness of tools like grep or sed would drop drastically, and we would fall back to big blobs of software. So you teach grep to take an IDL file, invoke an IDL compiler and dynamically load the parser for the protocol in question. Also, if the broker were a standardized, perhaps in-kernel component (dbus, kdbus), you could attach "idlgrep" to any process to trace its calls. You wouldn't be restricted to pipes. > Since I'm just passing data, do I really need the behavior attached to it? How would state persistence be handled? The parent's wording was a bit unfortunate. You can have interfaces and interface inheritance and versioning (the "OOP" part), but there's no behavior send between processes. > With object how many "translator" (C in the example) would you need to acheive the same result? Exactly one: the IDL compiler.