LENTS (Local Extendable Nested Tagging System) is an implementation of ENTS written in C that uses a custom binary file format as a database. It is the most hackerish version of ENTS, has the smallest database size, and was made as a low-level learning project. It is also named for the liturgical season it was started in, Lent.
LENTS usage
process
The output for lents process tags.yaml will always be to
a .lents hidden dot-file. This output cannot be changed,
for the sake of parsing.
The LENTS file format
- Terminology and stylistic choices
- Some set theory will be used in combination with colloquial English because it is the best way to communicate some things clearly and unambiguously
- Hex-line: refers to a standard 16-byte row in a hex dump
- Metadata: is a common term meaning “data about the data” used here.
- Ipsodata: contrasted with metadata. “Data that is
the data itself”. Commonly used English terms for “the data itself” such
as “core data”, “primary data”, “source data”, and “raw data” do not
capture what I want to mean here, the data itself which is
opposed to the data-about-the-data. Uses the Latin root
“ipso”, meaning “itself” as a prefix.
- Offset: When offset is said here, I am referring to only the length of the offset and not the content of the offset.
- Over-arching design choices for LENTS
- LENTS is a directed acyclic graph structure where hierarchically organized tags (nodes with parent-child relationships) map to files (destination nodes)
- The file format is designed for human-readability in hex dump
- File Header (32 Bytes, or 2 hex-lines)
- LENTS magic number in unicode
- Version number
- Offsets
- Start of tags ipsodata
- Start of file-to-tags metadata
- Start of file-to-tags ipsodata
- Data
Current implementations of LENTS use a structured a two-level index to two offset lookup tables (tags & file->tags) and the first table (tags) also has tag-to-files relationships. This is the most space-efficient representation for sparse relationships, but as relationships get denser there is a threshold after which it is more space-efficient to use a table encoding. The table encoding will be included in a future version of LENTS.
- Tags Data
Each tag ipsodata can vary significantly in length, so an offset table is used to save lots of file space at minimal expense of lookup time. All the attributes in the ipsodata can also vary in length from eachother, so a “tag individual ipsodata part length” field is needed in the metadata. Tag ipsodata offset is the distance measured from (3.3.a). The tag UUID is not neccassary for the tag ipsodata, but is included for debug purposes.
- Tags Metadata =
{
Tag Metadata}
- Tag Metadata = {Tag UUID, Tag ipsodata offset}
| Name | Size | Description |
| Tag Hash UID | 7 bytes | Hash of the tag name |
| Space for flags | 1 byte | Unused for now. May be used in future versions of LENTS while still being backwards compatible |
| Tag ipsodata offset | 4 bytes | Value of how far away from start-of-tags-ipsodata (3.3.a) the tag ipsodata is |
- Tags Ipsodata =
{
Tag Ipsodata}
- Tag Ipsodata = {Tag UUID, Tag name, Tag Ancestry UUIDs, Tag Children UUIDs}
- File-to-tags Relationship Data
The same heuristics about length variation and UUID-inclusion from (4) apply here. File-to-tags metadata starts at (3.3.b) and file ipsodata offset is the distance measured from (3.3.c).
- Files Metadata =
{
File Metadata}
- File Metadata = {File UUID, File individual ipsodata part length, File ipsodata offset}
- Files Ipsodata =
{
File Ipsodata}
- File Ipsodata = {File UUID, Tags UUIDs}