Documentation category

OpenDCS started as a school project, as that goes there’s usually a block of documents that are required to demonstrate that you know what you’re doing, even when you don’t. This level is probably mostly for that and some of it was/will be done under duress so try not to judge too harshly.

History

For the commit history of Dactl at the point that OpenDCS was forked see here.

Requirements

System Requirements Specification

This is a single document that describes the system as a whole, it can be read here.

Software Requirements Specification

All of the SRS documents are provided at the pages referenced in this list:

Design

Documentation

Valadoc Reference

The programming reference pages have been developed using the valadoc tool which generates its output from the comments contained in the class files.

REST API

DBus API

ZeroMQ API

Testing

Presentation

Posts

Nov 7, 2016

OpenDCS API

OpenDCS v0 is unstable and not recommended for production use. The intention of the API and structure for OpenDCS applications is that all will provide a single point of communication to their internals as well as that of others. For example API calls should be possible to make from a GUI addin plugin to the application that contains it and if the request is for a different host it should be passed along. read more…

Sep 21, 2016

Unit Tests in OpenDCS

The unit test framework that is used in OpenDCS is based off of the work done by the developers of libgee, specifically the TestCase class that extends what’s available in GTest which is included in GLib. read more…

Sep 12, 2016

Logging Backend Plugin Requirements

A logging backend plugin:

  • connects to or creates databases and files, eg. XML, hdf5, MariaDB
  • is configurable using a consistent DCS configuration format
  • describes the features it provides using mask-able flags
  • writes all data as a key/value pair where the key is a unique hash value
  • reads data back as an array of objects containing logged data
  • defines a filter for messages that it expects the daemon to receive and queue for it
  • receives all messages seen on the message queue it is connected to
  • sends messages for status, performance statistics, errors, etc. using the plugin’s unique identifier as the key to the message object

Features