integration.post

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