Hydrilla on-disk data format » History » Version 20
koszko, 01/19/2022 06:19 PM
change directory names from plural to singular
1 | 1 | koszko | # Hydrilla on-disk data format |
---|---|---|---|
2 | |||
3 | 18 | koszko | This page explains the upcoming format for built Hydrilla site content stored in the filesystem. It refers to the upcoming Hydrilla 1.0 release. |
4 | 1 | koszko | |
5 | 18 | koszko | You might also want to read about the format of [[Hydrilla source package format|Hydrilla source packages]] or about [[Repository API|Hydrilla HTTP JSON API]]. |
6 | |||
7 | 1 | koszko | {{toc}} |
8 | |||
9 | ## How Hydrilla loads content |
||
10 | 18 | koszko | Hydrilla expects a content directory to be specified in its configuration file (under the key "content-dir"). It then processes the following of its subdirectories. |
11 | 1 | koszko | |
12 | 20 | koszko | ### `file/` subdirectory |
13 | All files used by resources (either directly or as part of their source packages' license info) are stored under `file` with names of the format `sha256-<file's_sha256_sum>` |
||
14 | 1 | koszko | |
15 | 20 | koszko | ### `source/` subdirectory |
16 | Every resource and mapping in Hydrilla gets built from a source package. During building of each such source package a JSON description of it gets generated. All descriptions are stored under `source` with filenames of the format `<source_package_identifier>.json`. |
||
17 | 1 | koszko | |
18 | 18 | koszko | JSON descriptions of sources have structure as presented in the [[Repository API#Fetching source info|API description]]. They are served directly from disk files. In the future they will be accompanied by cryptographic signatures. |
19 | 1 | koszko | |
20 | 20 | koszko | Additionally, for each source package a zip archive with its contents is expected to be present under `source` with filename of the format `<source_package_identifier>.zip`. |
21 | 1 | koszko | |
22 | 20 | koszko | ### `resource/` subdirectory |
23 | All resource JSON descriptions are stored under `resource` with filenames of the format `<resource_identifier>/<resource_version_without_revision>.json`. For example, definitions of versions `0.1.0-4` and `0.1.1-1` of resource `hello` would be stored as `hello/0.1.json` and `hello/0.1.1.json`, respectively. Both would be under subdirectory `hello` of `resource`. |
||
24 | 1 | koszko | |
25 | 18 | koszko | JSON definitions of resources have structure as presented in the [[Repository API#Fetching resource info|API description]]. They are served directly from disk files. In the future they will be accompanied by cryptographic signatures. |
26 | 1 | koszko | |
27 | 20 | koszko | ### `mapping/` subdirectory |
28 | All mappings JSON descriptions are stored under `mapping` with filenames of the format `<mapping_identifier>/<mapping_version>.json`. For example, definitions of versions `0.1.0` and `0.1.1` of resource `hello` would be stored as `hello/0.1.json` and `hello/0.1.1.json`, respectively. Both would be under subdirectory `hello` of `mapping`. |
||
29 | 1 | koszko | |
30 | 18 | koszko | JSON descriptions of mappings have structure as presented in the [[Repository API#Fetching mapping info|API description]]. They are served directly from disk files. In the future they will be accompanied by cryptographic signatures. |
31 | 1 | koszko | |
32 | 18 | koszko | ## Populating Hydrilla content directory |
33 | Hydrilla package builder writes generated files in a way they are suitable to be loaded by Hydrilla. Given multiple already-populated content directories, it is also possible to recursively copy one's all contents into the other. In this case the user is responsible for avoiding clashes in identifiers of resources, mappings and sources. |