server-interface.post

   1 ;;;;;
   2 title: Server interface
   3 tags: tachikoma
   4 date: 2014-12-02 13:40:42
   5 format: md
   6 ;;;;;
   7
   8 What different components would a daemon expose via the message bus,
   9 respectively knowledge store?
  10
  11 For one, methods for remote control.  Since RPCs aren't very flexible,
  12 the communication style should use message passing.  Waiting for
  13 response needs to be both aware of possible timeouts and communication
  14 failures.
  15
  16 Passed objects can't be too complex, since every interacting
  17 language/environment needs to be able to access, create, possibly
  18 manipulate them, as well as to minimize the amount of overhead during
  19 serialisation.  At the same time the schema of messages isn't fixed, so
  20 there is an obvious problem for very strict type systems, in that either
  21 a fixed-schema wrapper can be used, which would need to be updated at
  22 some point, or be kept backwards-compatible, or a very dynamic
  23 representation with runtime checks would have to be implemented.
  24
  25 Comparable string based messages from e.g. Plan9 are too simple on the
  26 one hand, whereas a protocol like DBus might be overengineered(?).
  27
  28 An important point to consider is the in(tro)spection features of the
  29 global system.  It should be absolutely possible to easily see and edit
  30 messages as well as stored data in either a text-based or convertible
  31 format.  Also, commands and objects should have runtime documentation in
  32 the system, so that a hypothetical call like `describe object` would
  33 display text- (in the terminal), or hypertext based documentation (in
  34 the browser).
  35
  36 Naming clashes have to be solved by a one or multi level package system.
  37 Since the naming is both shared and global, typical approaches include
  38 reversed domain-names, UUIDs and prefixing of identifiers.
  39
  40 Session management would include saving and reloading of state, even
  41 with different session names.  A separate session manager would take
  42 care of initialising applications based on the saved state.
  43
  44 For both text- and graphical UIs methods to switch to the active
  45 screen/window need to be provided.  Copy & paste functionality might
  46 still be done via the window system, or additionally via messaging,
  47 which would allow connected system, as well as text and graphical
  48 applications to exchange content without any problems.