From 45a829bbe9e2977dc235fa22e9fab5d20ad25cb7 Mon Sep 17 00:00:00 2001 From: Olof-Joachim Frahm Date: Sun, 30 Nov 2014 20:49:08 +0100 Subject: [PATCH] Add new post about IPC and programs. --- programs-ipc.post | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 programs-ipc.post diff --git a/programs-ipc.post b/programs-ipc.post new file mode 100644 index 0000000..a4df25d --- /dev/null +++ b/programs-ipc.post @@ -0,0 +1,82 @@ +;;;;; +title: IPC and knowledge store programs +tags: tachikoma +date: 2014-11-30 15:32:23 +format: md +;;;;; + +What kind of applications aren't easily possible without a central +message bus / knowledge store? Or rephrased as what kind of +applications would benefit very much from the use of a central message +bus / knowledge store. + +To answer this, let's see how IPC usually works between applications: +If a program wants to communicate with other parts of the system, there +are several options, including writing data to a regular file, +pipe/fifo, or socket, as well as directly executing another program. In +some cases the communication style is uni-directional, in some +bi-directional. + +So depending on the setup you can pretty much exactly define how +messages are routed between components. However, the details of this +communication are hidden from the outside. If you wanted react to one +message from another part of the system, you're out of luck. This +direct coupling between components doesn't lend itself very well to +interception and rerouting. + +Unless the program of your choice is very scriptable, you then have no +good way to e.g. run a different editor for a file to be opened. Since +programs typically don't advertise their internal capabilities to +outside use (like CocoaScript (?) allows you to a degree), you also +don't have a chance to react to internal events of a program. + +Proposed changes to browsers would include decoupling of bookmark +handling, cookies/session state, notifications and password management. +Additionally it would be useful to expose all of the scripting interface +to allow for external control of tabs and windows, as well as possible +hooking into website updates, but I think that part is just a +side-effect of doing the rest. + +Proposed changes to IRC clients / instant messengers would include +decoupling of password management and notifications. Additionally the +same argument to expose channels/contacts/servers to external +applications applies. + +Now let's take a look at the knowledge store. In the past I've used a +similar Blackboard system to store sensor data and aggregate knowledge +from reasoners. The idea behind that is the decoupling of different +parts of the program from the data they work on, reacting to input data +if necessary and outputting results for other programs to work on. + +I imagine that this kind of system relieves programs from creating their +own formats for storing data, as well as the need to explicitly specify +where to get data from. Compared to a RDBMS to downside is obviously +the lack of a hard schema, so the same problems from document based +data-stores apply here. Additionally the requirement to have triggers +in order to satisfy the subscriptions of clients makes the overall model +more complex and harder to optimise. + +What is then possible with such a system? Imagine having a single +command to switch to a specific buffer regardless of how many programs +are open and whether they use a MDI or just a single window. In general +scripting of all running programs will be easier. + +The knowledge store on the other hand could be used to hold small +amounts of data like contacts, the subjects of the newest emails, +notifications from people and websites. All of that context data is +then available for other programs to use. + +Assuming such data was then readily available, using ML to process at +least some of the incoming data to look for important bits of +information (emails/messages from friends/colleagues, news stories) can +then create an additional database of "current events". How this is +displayed is again a different problem. The simplest approach would +simply be a ticker listening on a specific query, the most complex would +maybe consist of whole graphical dashboard. + +Security is obviously a problem in such a share-all approach. It should +be possible though to restrict access to data similarly to how user +accounts in regular DBM systems work and for scripting interactions the +system would still have to implement restrictions based on the +originating user and group on a single system, as well as the host in a +distributed environment. -- 1.7.10.4