From: Olof-Joachim Frahm Date: Tue, 2 Dec 2014 13:38:43 +0000 (+0100) Subject: Add server interface post. X-Git-Url: http://repo.macrolet.net/gitweb/?a=commitdiff_plain;h=378fe9c8ee5c279af210d27189049f7406080810;p=blog.git Add server interface post. --- diff --git a/pim-daemon.post.unpublished b/pim-daemon.post.unpublished new file mode 100644 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 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.