aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBryan Newbold <bnewbold@archive.org>2022-06-24 19:53:25 -0700
committerBryan Newbold <bnewbold@archive.org>2022-06-24 19:53:25 -0700
commit618af47ac66f4109ae605773eaf60e933323a5ef (patch)
tree4490fffeffa7b00682c16cb12c965ee8d80f5966
parent0ac571f41a2a0be84dbd360805e3c4e51686681d (diff)
downloadaft-master.tar.gz
aft-master.zip
commit old updates to READMEHEADmaster
-rw-r--r--README.md21
1 files changed, 19 insertions, 2 deletions
diff --git a/README.md b/README.md
index b2abfd7..b3d80c9 100644
--- a/README.md
+++ b/README.md
@@ -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`?