Changelog and roadmap

Changelog

0.5.1

• GPG signing package, setting up the build chain (read the docs, pypi ...)
• making sure README.rst is both used in docs and pypi description

0.5.0

Initial release.

Convention:

version x.y.z

while in beta convention is :

• x = 0
• y = API change
• z = bugfix and/or improvement

and then

• x = API change
• y = improvement
• z = bugfix

Roadmap

0.6.1

• introducing a garbage collector that can serialize buffer on disk
• going tornado

0.6

Make a full functionnal testing framework so people can build their own topology and measure impacts of choices. When it works for me (tm) switch to beta.

TODO limitations

• OOP to reduce the repeating of args in function calls

• in the tests with carbon clean hierarchy of metrics

• implements a simple router

• binary star on more than one server orchester

• find a way to deploy and package satellites set

• find a consistent naming (power of analogy will go full retarded with

  astronomy)

• ease the multi hosts satellites connection

• invent a way to modify the code in the orchester for routing by using

PUB/SUB for rerouting informations simplified coroutines (going the bright side of 10th greenspun law and assumming to borrow the concepts of CLISP)

• make it easy to change the serialization format (utlimately find a way

  to use pack and unpack to go full speed and ease the transmission of data coming from C)

• promote the use of badass archery library and its confusing naming because

  I hate humanity (some people wants to watch the world burn)

• reduce code, improve reliability, reduce functionnalities to have a better code

• Maybe draw attention to developers that they are totally acculturated and

  re explain some basics of networks/system so that they are aware that their ignorance may cause security issues. Highlight the fact that powerfull tools are a way to shoot yourself a nuclear missile in the knee

• ERROR HANDLING even I is not totally top notch on the topic, find a subset

  of best practices that prevents a DOS by repeated failures of do something at the orchester/tracker level to actively modify routing/ alert when something goes wrong

• Use pytables to store efficiently messages in a hierarchical way for messages

  that are critical and need to be replayed

• write the limitations : THIS CANNOT BE ACID BY DEFINITION, like any

  distributed systems. (can be improved later by using PAIR of REP/REQ for statefull connections that should make it reliable enough if you had a on_happy end hook)

• write a tracker that takes full use of the FSM and implement the time_out stuff

• put a notice about the halting problem and how we cannot differenciate a code

  in an infinite loop and a processing that takes a lot of time

• put a notice on how to design asynch system: bottom half architecture: satellites are bottom halfs.

• put a link to the fact that a complex system is by nature non deterministic

  (yes it is chaotic, but compared to systemd my architecture embrace complexity and the positive property of complex systems such as the resilience to perturbations)

• a big chapter on clock and time and distributed system, and how

  you don’t really need to read the indigests pedantic INRIA papers on vector clock to make a distributed systems works correctly without clock (hint : time is the accident of the accidents)