diff options
author | Bryan Newbold <bnewbold@archive.org> | 2022-06-24 19:53:25 -0700 |
---|---|---|
committer | Bryan Newbold <bnewbold@archive.org> | 2022-06-24 19:53:25 -0700 |
commit | 618af47ac66f4109ae605773eaf60e933323a5ef (patch) | |
tree | 4490fffeffa7b00682c16cb12c965ee8d80f5966 | |
parent | 0ac571f41a2a0be84dbd360805e3c4e51686681d (diff) | |
download | aft-master.tar.gz aft-master.zip |
-rw-r--r-- | README.md | 21 |
1 files changed, 19 insertions, 2 deletions
@@ -58,6 +58,14 @@ General structure of tables is: Comments and annotations are not supported. +Default strings must not contain any of the special characters. This must be +enforced by code doing the encoding, and requires a full pass of every value. +In this mode, strings which include the special characters may not be included +and must raise an error. For UTF-8 strings which may include the characters, an +escaped column type is allowed, which allows arbitrary JSON-style character +escapes (like '\u01`). The downside with this mode is that conversion and +processing may be slower. + ## Extras Text editor support: coloring, easy entry of special chars, highlighting @@ -69,11 +77,13 @@ Unfortunately, my terminal (xterm) interprets Ctrl-V Ctrl-_ as "resize smaller". Encoding is that of JSON or TOML. Values can be: -- string (UTF-8) (default if not specifier) +- string (UTF-8) (default if not specified) +- escaped byte-string, JSON-style +- base64 encoded bytes - integer number - floating point number - boolean -- date, timestamp +- date, timestamp (ISO format) - null ## Usage Examples @@ -113,3 +123,10 @@ Encoding is that of JSON or TOML. Values can be: group separator instead of newline? single mode is much better, but compatibility with existing UNIX-y newline-oriented stuff also compelling. Hrm. - should first line in file starting with `#` be ignored? for future extensibility +- should the default mode be escaped strings, or strings with no special + characters allowed? may not matter for the common case of no special characters. +- should additional constraints be placed on header encoding? eg, that they + must be escaped or not have any ASCII special characters. this might make + parsing to determine validity and mode easier +- should there be fast ASCII-only, no special characters mode? would that + provide even more speed? `daft`? |