programs-ipc.post

   1 ;;;;;
   2 title: IPC and knowledge store programs
   3 tags: tachikoma
   4 date: 2014-11-30 15:32:23
   5 format: md
   6 ;;;;;
   7
   8 What kind of applications aren't easily possible without a central
   9 message bus / knowledge store?  Or rephrased as what kind of
  10 applications would benefit very much from the use of a central message
  11 bus / knowledge store.
  12
  13 To answer this, let's see how IPC usually works between applications:
  14 If a program wants to communicate with other parts of the system, there
  15 are several options, including writing data to a regular file,
  16 pipe/fifo, or socket, as well as directly executing another program.  In
  17 some cases the communication style is uni-directional, in some
  18 bi-directional.
  19
  20 So depending on the setup you can pretty much exactly define how
  21 messages are routed between components.  However, the details of this
  22 communication are hidden from the outside.  If you wanted react to one
  23 message from another part of the system, you're out of luck.  This
  24 direct coupling between components doesn't lend itself very well to
  25 interception and rerouting.
  26
  27 Unless the program of your choice is very scriptable, you then have no
  28 good way to e.g. run a different editor for a file to be opened.  Since
  29 programs typically don't advertise their internal capabilities to
  30 outside use (like CocoaScript (?) allows you to a degree), you also
  31 don't have a chance to react to internal events of a program.
  32
  33 Proposed changes to browsers would include decoupling of bookmark
  34 handling, cookies/session state, notifications and password management.
  35 Additionally it would be useful to expose all of the scripting interface
  36 to allow for external control of tabs and windows, as well as possible
  37 hooking into website updates, but I think that part is just a
  38 side-effect of doing the rest.
  39
  40 Proposed changes to IRC clients / instant messengers would include
  41 decoupling of password management and notifications.  Additionally the
  42 same argument to expose channels/contacts/servers to external
  43 applications applies.
  44
  45 Now let's take a look at the knowledge store.  In the past I've used a
  46 similar Blackboard system to store sensor data and aggregate knowledge
  47 from reasoners.  The idea behind that is the decoupling of different
  48 parts of the program from the data they work on, reacting to input data
  49 if necessary and outputting results for other programs to work on.
  50
  51 I imagine that this kind of system relieves programs from creating their
  52 own formats for storing data, as well as the need to explicitly specify
  53 where to get data from.  Compared to a RDBMS to downside is obviously
  54 the lack of a hard schema, so the same problems from document based
  55 data-stores apply here.  Additionally the requirement to have triggers
  56 in order to satisfy the subscriptions of clients makes the overall model
  57 more complex and harder to optimise.
  58
  59 What is then possible with such a system?  Imagine having a single
  60 command to switch to a specific buffer regardless of how many programs
  61 are open and whether they use a MDI or just a single window.  In general
  62 scripting of all running programs will be easier.
  63
  64 The knowledge store on the other hand could be used to hold small
  65 amounts of data like contacts, the subjects of the newest emails,
  66 notifications from people and websites.  All of that context data is
  67 then available for other programs to use.
  68
  69 Assuming such data was then readily available, using ML to process at
  70 least some of the incoming data to look for important bits of
  71 information (emails/messages from friends/colleagues, news stories) can
  72 then create an additional database of "current events".  How this is
  73 displayed is again a different problem.  The simplest approach would
  74 simply be a ticker listening on a specific query, the most complex would
  75 maybe consist of whole graphical dashboard.
  76
  77 Security is obviously a problem in such a share-all approach.  It should
  78 be possible though to restrict access to data similarly to how user
  79 accounts in regular DBM systems work and for scripting interactions the
  80 system would still have to implement restrictions based on the
  81 originating user and group on a single system, as well as the host in a
  82 distributed environment.