Name: Delete /meta/ 2016-07-06 18:24
Step 1: Be fundamentally wrong about IPC
It's important that you misunderstand that practically all communication is done in a server-client model. You need to introduce a new daemon to be the server, and effectively enforce a client-client model, so as to maximize confusion and minimize performance.
Step 2: Nothing must ever be a file
To design a good IPC system, you must ensure it cannot work with common tools such as cat or echo. You need to design it in such a way that nothing ever touches the file system and, by extension, everything must go through your tool. This is Unix. A tool may only serve one purpose and IPC is one thing, so don't let others encroach on your territory.
Step 3: Tools are complicated - users need to feel that
In order to convey just how complicated your introspection tool is, you need to --use-many-long-options and --change-them-frequently. If you don't, people might be able to remember how to use your tool and that's obviously a problem.
Step 4: "Servers" must be difficult to write and require special metacompilers
If you make it easy to write servers, people will actually write servers. This is the opposite of what you want. You need it to be so exceptionally difficult that people would rather produce a full distribution image with their software in it than try to make simple service oriented programs. It's much better to link in all things you need than have things run out of process after all. A good way to achieve this would be to require all calls to be defined ahead of time in a format like XML and use it to generate code, while requiring people to use introspection at runtime to actually do anything.
Step 5: Have multiple instances of the unnecessary facilitator daemon running at all times.
To ensure maximum pain and minimum usefulness, you need to have multiple daemons running. You also need to make connecting to the daemon transparent so that you control which one your users connect to. By doing this you can, seemingly at random, connect them to the wrong one and spam their machines with incomprehensible errors. Punishing users for mistakes they didn't even make is a great way to generate support business.
Step 6: If performance is bad blame everyone else
Suppose people start complaining about performance, what you need to do is to find a scapegoat. The kernel is a good one since few people actually understand it. It also means you get to commit code to the kernel. If, heaven forbid, someone should protest this, you've actually won. You will have successfully shifted the focus from criticizing your terrible IPC mechanism to criticizing your irrelevant kernel patches. In the future you might have to keep creating new, incompatible codepaths to your system to keep people chasing you, or they might remember that its your IPC mechanism that's unworkable and not the latest hot topic item you created.
It's important that you misunderstand that practically all communication is done in a server-client model. You need to introduce a new daemon to be the server, and effectively enforce a client-client model, so as to maximize confusion and minimize performance.
Step 2: Nothing must ever be a file
To design a good IPC system, you must ensure it cannot work with common tools such as cat or echo. You need to design it in such a way that nothing ever touches the file system and, by extension, everything must go through your tool. This is Unix. A tool may only serve one purpose and IPC is one thing, so don't let others encroach on your territory.
Step 3: Tools are complicated - users need to feel that
In order to convey just how complicated your introspection tool is, you need to --use-many-long-options and --change-them-frequently. If you don't, people might be able to remember how to use your tool and that's obviously a problem.
Step 4: "Servers" must be difficult to write and require special metacompilers
If you make it easy to write servers, people will actually write servers. This is the opposite of what you want. You need it to be so exceptionally difficult that people would rather produce a full distribution image with their software in it than try to make simple service oriented programs. It's much better to link in all things you need than have things run out of process after all. A good way to achieve this would be to require all calls to be defined ahead of time in a format like XML and use it to generate code, while requiring people to use introspection at runtime to actually do anything.
Step 5: Have multiple instances of the unnecessary facilitator daemon running at all times.
To ensure maximum pain and minimum usefulness, you need to have multiple daemons running. You also need to make connecting to the daemon transparent so that you control which one your users connect to. By doing this you can, seemingly at random, connect them to the wrong one and spam their machines with incomprehensible errors. Punishing users for mistakes they didn't even make is a great way to generate support business.
Step 6: If performance is bad blame everyone else
Suppose people start complaining about performance, what you need to do is to find a scapegoat. The kernel is a good one since few people actually understand it. It also means you get to commit code to the kernel. If, heaven forbid, someone should protest this, you've actually won. You will have successfully shifted the focus from criticizing your terrible IPC mechanism to criticizing your irrelevant kernel patches. In the future you might have to keep creating new, incompatible codepaths to your system to keep people chasing you, or they might remember that its your IPC mechanism that's unworkable and not the latest hot topic item you created.