From 71be5653c26fb007c700a9cedcee279f3f75db27 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A1szl=C3=B3=20Monda?= Date: Sat, 9 Apr 2016 14:59:47 +0200 Subject: [PATCH] Update README.md --- config-serializer/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config-serializer/README.md b/config-serializer/README.md index b438b9f8..dcb200e3 100644 --- a/config-serializer/README.md +++ b/config-serializer/README.md @@ -10,7 +10,7 @@ There are 3 different representations of the configuration, each filling a speci The **JavaScript representation** is optimally suited to be serialized as JSON, and saved to the file system, or transmitted over the network. As a plaintext format, it's human-readable and easily editable. See [uhk-config.json](uhk-config.json) for an example configuration. -The **TypeScript representation** is structurally similar to the JavaScript representation, but it features strongly typed TypeScript objects instead of typeless JavaScript objects. This representation is meant to be used by Agent. Extensive validation takes place upon initializing the TypeScript objects to ensure the integrity of the configuration. +The **TypeScript representation** is structurally similar to the JavaScript representation, but it features strongly typed TypeScript objects instead of typeless JavaScript objects. This representation is meant to be used by Agent. Extensive, per-property [assertion](assert.ts) takes place upon initializing the TypeScript objects to ensure the integrity of the configuration. The **binary representation** is meant to be written to, and read from the EEPROM of the UHK. It's designed to be very compact in order to maximize the use of the 32kbyte EEPROM space.