Add server interface post.

diff --git a/pim-daemon.post.unpublished b/pim-daemon.post.unpublished
new file mode 100644 (file)
index 0000000..6831179
--- /dev/null
+++ b/pim-daemon.post.unpublished
@@ -0,0 +1,7 @@
+- Natural language processing for parsing and understanding parts of
+  messages from/to the user.
+- Scheduling of appointments and waiting for responses with reasonable
+  answer durations
+- Keeping track of people's status, including vacations, but also
+  obvious activity via email, instant messaging and other APIs
+  (e.g. Github).

diff --git a/server-interface.post b/server-interface.post
new file mode 100644 (file)
index 0000000..12cb388
--- /dev/null
+++ b/server-interface.post
@@ -0,0 +1,48 @@
+;;;;;
+title: Server interface
+tags: tachikoma
+date: 2014-12-02 13:40:42
+format: md
+;;;;;
+
+What different components would a daemon expose via the message bus,
+respectively knowledge store?
+
+For one, methods for remote control.  Since RPCs aren't very flexible,
+the communication style should use message passing.  Waiting for
+response needs to be both aware of possible timeouts and communication
+failures.
+
+Passed objects can't be too complex, since every interacting
+language/environment needs to be able to access, create, possibly
+manipulate them, as well as to minimize the amount of overhead during
+serialisation.  At the same time the schema of messages isn't fixed, so
+there is an obvious problem for very strict type systems, in that either
+a fixed-schema wrapper can be used, which would need to be updated at
+some point, or be kept backwards-compatible, or a very dynamic
+representation with runtime checks would have to be implemented.
+
+Comparable string based messages from e.g. Plan9 are too simple on the
+one hand, whereas a protocol like DBus might be overengineered(?).
+
+An important point to consider is the in(tro)spection features of the
+global system.  It should be absolutely possible to easily see and edit
+messages as well as stored data in either a text-based or convertible
+format.  Also, commands and objects should have runtime documentation in
+the system, so that a hypothetical call like `describe object` would
+display text- (in the terminal), or hypertext based documentation (in
+the browser).
+
+Naming clashes have to be solved by a one or multi level package system.
+Since the naming is both shared and global, typical approaches include
+reversed domain-names, UUIDs and prefixing of identifiers.
+
+Session management would include saving and reloading of state, even
+with different session names.  A separate session manager would take
+care of initialising applications based on the saved state.
+
+For both text- and graphical UIs methods to switch to the active
+screen/window need to be provided.  Copy & paste functionality might
+still be done via the window system, or additionally via messaging,
+which would allow connected system, as well as text and graphical
+applications to exchange content without any problems.