Why we use KDL (Kuddly, Cuddly document Language)

Created: 2024.02.03

Overview

TL;DR
We use KDL (Kuddly/Cuddly document Language) where we expect customers that is "humans" will be in a variety of circumstances, reading and/or editing the data. We picked it because it is a flexible, easy syntax that minimizes mistakes caused by not following (very picky) details of other forms of data.

We also use ITIQDoc, YAML, TAML, XML, Databases including SQL on servers and various options including IndexedDB in browsers and client side apps such as Android apps and Apple apps, and we even use plain text and files in a directory and more in various places, based on what we think is best for the purpose.

Details
We use several different formats for data, ranging from SQL to Text, ranging from JSON to YAML to XML to TAML

There are generally three different ways at a high level differentiating how we store data.

For human consumption the goals are:

Reliable, non-ambiguous
Easy for a human to read
Easy for a human to write and edit correctly without making mistakes that will be missed by the program reading it.
Note that forward compatible is not one of the requisites. While we aim for this generally, a human isn't typically going to be put out a lot by format changes, especially if it makes it easier for them to work with. In cases like our configuration, if we update the format, they can just do a new export in the new format.

For transferring data from one system to another the goals are:

Reliable
Forward compatible
Small (relates to speed)

For storing data in a server or on your cell phone or other local device the goals are:

Reliable Forward compatible In some cases "ACID" is a requirement, such as transactional data.

And then there are a few more:

Warehouse data

  • We don't do a lot of this, pun intended if you understand warehouse data, it is more based on the software that will be accessing it.

Backups

Reliable
Fast to save
But note that fast to retrieve is often not one of the requisites.

KDL supports the "for human consumption" goal. So in places where we expect users (with help from expert support people) to:

  • Read configuration information, looking for causes of problems typically
  • Edit configuration information, an easy way to edit then import back or import configuration information into another database