integration.post

   1 ;;;;;
   2 title: Integrated tools
   3 date: 2014-11-27 23:30:22
   4 format: md
   5 ;;;;;
   6
   7 Continuing that thought, I feel that the tools we use are very much
   8 disconnected from each other.  Of course that is the basic tenet, tools which
   9 do one thing well.  However, tools serve a specific purpose, which in itself
  10 can be characterised as providing a specific service.  It seems strange that
  11 basically the only widely applicable way to connect very different tools is the
  12 shell, respectively calling out to other programs.
  13
  14 I would argue that using some another paradigms could rather help to make the
  15 interplay between services in this sense much easier.  For example, if we were
  16 to use not only a message bus, line in Plan9, but also a shared blackboard-like
  17 database to exchange messages in a common format, then having different daemons
  18 react on state changes would be much easier.
  19
  20 Of course, this would already be possible if the one point, a common exchange
  21 format, was satisfied.  In that case, using file system notifications together
  22 with files, pipes, fifos etc. would probably be enough to have largely the same
  23 system, but based on the file system abstraction.
  24
  25 Imagine now, that programs actually were actually reusing functionality from
  26 other services.  My favourite pet-peeve would be a shared bookmark list, cookie
  27 store, whatever browsers typically reimplement.  It should be no surprise that
  28 very focused browsers like `uzbl` actually do just that, allowing for the
  29 combination of different programs rather then the reimplementation of basic
  30 components.
  31
  32 It's unfortunate that tools like `mailcap` and `xdg-open` aren't very
  33 integrated into shell workflow.  Even though names like `vim`, or `feh` are
  34 muscle-memory for me, having unified generic nomenclature for actions like
  35 open, edit would be very helpful as a first step into a more programmable
  36 environment.  Plan9-like decision-making for how to respond to these requests,
  37 or like the aforementioned blackboard/messaging architecture all go into the
  38 same direction.
  39
  40 If we now compare how command-line tools respond to queries, so for an abstract
  41 command like `help` it would naturally be `foo --help` (and shame on you if
  42 your tool then outputs "Use `man foo`."; `git` does it right fortunately), then
  43 we can see how we can procede from here.  Not only should we adapt these kind
  44 of queries, but reflectivity is absolutely necessary to provide a more
  45 organised system.
  46
  47 Even though "worse is better", it hinders the tighter linking of tools, as
  48 everything first goes to serialised form, then back through the OS layers.
  49 Despite dreaming of a more civilised age (you know, Lisp Machines), a
  50 compromise based on light-weight message-passing in a service-based approach,
  51 relying on deamons as the implementation detail to provide functionality could
  52 be viable.  Essentially, what can't be done in a single global memory space we
  53 emulate.
  54
  55 Sounds awfully like CORBA and DBUS, right?  Well I think an important
  56 consideration is the complexity of the protocol versus the effort spent on
  57 integration.  If it is very easy to link existing applications up to the
  58 message bus and if that system allows not only message passing, but also
  59 provides styleguides and an implementation of the basic interaction schemes
  60 (RPC call, two-way communication, ...), then what sounds otherwise like a lot
  61 of reimplementation might actually be more like leveraging existing
  62 infrastructure instead.