List view

• Event Sourcing

  Convert the code base to use an event sourcing architecture, where current state can be derived from replaying all the changes. Support optional snapshots for performance. This model allows for a multi-master set-up later, by extending the storage component to be aware of a clustered key-value store of sorts. Also allows for a message driven architecture, e.g. when a CA has new things produced, this can send a message of the event for asynchronous publication by some other thread. So this should help scaling.

  Due by May 1, 2019

  •2/2 issues closed
  100% complete0 open2 closed

• Interface Foundation

  Set up the basic API, UI and CLI interface to the server. Until now we only focussed on having a configuration file, but no dynamic interface is present. Publishers can be added by dropping the id.xml files in the right folder, and there are some scattered pages with info. This was fine to get started, but now some work is needed to set up an API, UI and CLI. The current functionality and pages will be ported into this. Going forward it's implied that all features will come with an appropiate interface.

  Due by February 1, 2019

  •8/8 issues closed
  100% complete0 open8 closed

• Basic Publication Server

  The publication server will be used by the CAs - which will then have the option of either using it as embedded, or remote. The CA code will go into the same code base, because there is a lot of synergy in architecture and libraries required. Also it makes embedding a pub server much cheaper.

  Due by January 1, 2019

  •1/1 issues closed
  100% complete0 open1 closed