1. 19 Jul, 2018 1 commit
  2. 17 Jul, 2018 3 commits
  3. 16 Jul, 2018 3 commits
  4. 03 Jul, 2018 3 commits
  5. 25 May, 2018 4 commits
  6. 18 May, 2018 1 commit
    • Swann Perarnau's avatar
      [refactor] convert the project to Pipenv · 8e41f7a1
      Swann Perarnau authored
      Pipenv provides a reproducible description of the python packages
      necessary for a python application. See the Pipenv documentation for
      reference.
      
      We also remove tox from the repo, relying instead directly on pytest.
      Since we only supported one version of python, that's not a big deal.
      8e41f7a1
  7. 13 Feb, 2018 2 commits
  8. 21 Dec, 2017 2 commits
  9. 20 Dec, 2017 6 commits
  10. 19 Dec, 2017 12 commits
  11. 18 Dec, 2017 3 commits
    • Swann Perarnau's avatar
      [feature] Implement skeleton downstream API · 19c9eb54
      Swann Perarnau authored
      This patch refactors the downstream API to use pub/sub socket pair, like
      the upstream API. This is part of the effort to improve the downstream
      API. See #2.
      
      This patch doesn't touch the client module, which will be adapted in
      future commits.
      19c9eb54
    • Swann Perarnau's avatar
      Merge branch 'upstream-network-fixes' into 'master' · be059812
      Swann Perarnau authored
      Fix upstream publishers messaging issues
      
      See merge request !8
      be059812
    • Swann Perarnau's avatar
      [refactor] daemon should always bind on sockets · 1391a197
      Swann Perarnau authored
      The way 0MQ works on PUB/SUB sockets, publishers might drop
      messages if subscribers are not detected faster enough. One way to fix
      it is to have the "server" always bind sockets, and the "client" use
      connect. This way, the handshake is initiated properly, and the client
      can publish as soon as the connection is done.
      
      This patch makes the daemon bind on the upstream API and the CLI connect,
      fixing in the process the message dropping we were experiencing before.
      
      Long term, we might have a think of using 2 types of sockets for the
      upstream API: pub/sub for actual events published from the daemon, and
      a REQ/REP or ROUTER/DEALER pair for "commands".
      1391a197