Expand on the integration post.

diff --git a/integration.post b/integration.post
index 73749cc..025cead 100644 (file)
--- a/integration.post
+++ b/integration.post
@@ -1,11 +1,11 @@
 ;;;;;
 title: Integrated tools
-date: 2014-11-27 21:30:21
+date: 2014-11-27 23:30:22
 format: md
 ;;;;;
 
 Continuing that thought, I feel that the tools we use are very much
-disconnected from each other.  Of course that is the basic tennet, tools which
+disconnected from each other.  Of course that is the basic tenet, tools which
 do one thing well.  However, tools serve a specific purpose, which in itself
 can be characterised as providing a specific service.  It seems strange that
 basically the only widely applicable way to connect very different tools is the
@@ -21,3 +21,42 @@ Of course, this would already be possible if the one point, a common exchange
 format, was satisfied.  In that case, using file system notifications together
 with files, pipes, fifos etc. would probably be enough to have largely the same
 system, but based on the file system abstraction.
+
+Imagine now, that programs actually were actually reusing functionality from
+other services.  My favourite pet-peeve would be a shared bookmark list, cookie
+store, whatever browsers typically reimplement.  It should be no surprise that
+very focused browsers like `uzbl` actually do just that, allowing for the
+combination of different programs rather then the reimplementation of basic
+components.
+
+It's unfortunate that tools like `mailcap` and `xdg-open` aren't very
+integrated into shell workflow.  Even though names like `vim`, or `feh` are
+muscle-memory for me, having unified generic nomenclature for actions like
+open, edit would be very helpful as a first step into a more programmable
+environment.  Plan9-like decision-making for how to respond to these requests,
+or like the aforementioned blackboard/messaging architecture all go into the
+same direction.
+
+If we now compare how command-line tools respond to queries, so for an abstract
+command like `help` it would naturally be `foo --help` (and shame on you if
+your tool then outputs "Use `man foo`."; `git` does it right fortunately), then
+we can see how we can procede from here.  Not only should we adapt these kind
+of queries, but reflectivity is absolutely necessary to provide a more
+organised system.
+
+Even though "worse is better", it hinders the tighter linking of tools, as
+everything first goes to serialised form, then back through the OS layers.
+Despite dreaming of a more civilised age (you know, Lisp Machines), a
+compromise based on light-weight message-passing in a service-based approach,
+relying on deamons as the implementation detail to provide functionality could
+be viable.  Essentially, what can't be done in a single global memory space we
+emulate.
+
+Sounds awfully like CORBA and DBUS, right?  Well I think an important
+consideration is the complexity of the protocol versus the effort spent on
+integration.  If it is very easy to link existing applications up to the
+message bus and if that system allows not only message passing, but also
+provides styleguides and an implementation of the basic interaction schemes
+(RPC call, two-way communication, ...), then what sounds otherwise like a lot
+of reimplementation might actually be more like leveraging existing
+infrastructure instead.