Project

General

Profile

Hydrilla on-disk data format » History » Version 7

koszko, 11/12/2021 11:15 AM
minor corrections

1 1 koszko
# Hydrilla on-disk data format
2
3
This page explains the upcoming format for Hydrilla site content stored in the filesystem. It refers to the upcoming Hydrilla 0.2 release.
4
5
{{toc}}
6
7
## How Hydrilla loads content
8
9
Hydrilla expects a content directory to be specified in its configuration file (under the key "content-dir"). It then processes all its direct subdirectories. If given subdirectory contains an `index.json` file, Hydrilla loads it (smartly ignoring '//' comments in it) and collects the definitions of site resources, pattern->payload mappings and licenses in it.
10
11
## Format of an index.json
12
13
To understand the format, look into this example file with explanatory comments in it:
14
15
``` javascript
16
// SPDX-License-Identifier: CC0-1.0
17
18
// Copyright (C) 2021 Wojtek Kosior
19
// Available under the terms of Creative Commons Zero v1.0 Universal.
20
21
// This is an example index.json file describing Hydrilla site content. As you
22
// can see, for storing site content information Hydrilla utilizes JSON with an
23
// additional extension in the form of '//' comments support. Hydrilla shall
24
// look into each direct subdirectory of the content directory passed to it
25
// (via a cofig file option). If such subsirectory contains an index.json file,
26
// Hydrilla shall process it.
27
28
// An index.json file conveys definitions of site resources, pattern->payload
29
// mappings and licenses thereof. The definitions may reference files under
30
// index.json's containing directory, using relative paths. This is how scripts,
31
// license texts, etc. are included. Unix paths (using '/' as separator) are
32
// assumed. It is not allowed for an index.json file to reference files outside
33
// its directory.
34
35 5 koszko
// Certain objects are allowed to contain a "comment" field. Although '//'
36
// comments can be used in index.json files, they will be stripped when the file
37
// is processed. If a comment should be included in the JSON definitions served
38
// by Hydrilla API, it should be put in a "comment" field of the proper object.
39
40 7 koszko
// Various kinds of objects contain version information. Version is always an
41
// array of integers, with major version number being the first array item. When
42
// applicable, a version might be accompanied by a revision field which contains
43
// a positive integer and is optional (defaults to 1 if not specified). If
44
// versions specified by arrays of different length need to be compared, the
45
// shorter array gets padded with zeroes on the right. This means that for
46
// example version 1.3 could be given as both [1, 3] and [1, 3, 0, 0]
47
// (aka 1.3.0.0) and either would mean the same.
48
49 1 koszko
{
50 7 koszko
    // Once our json schema changes, this version will change. Our software will
51 1 koszko
    // be able to handle both current and older formats thanks to this
52 7 koszko
    // information present in every index.json file. Different schema versions are always incompatible (e.g. a Hydrilla instance that understands schema version 0.2.0.0 will not understand version 0.2.0.1). Schemas that are backwards-compatible will be denoted by a different revision.
53
    // We will try to make schema version match the version of Hydrilla software that introduced it.
54
    "schema_version": [0, 2],
55
    // 1 is the default revision. We could have as well just skipped this field.
56
    "schema_revision": 1,
57 1 koszko
58
    // Copyright of this json file. It's a list of copyright holder information
59
    // objects. Alternatively, "auto" can be used to make Hydrilla attempt to
60
    // extract copyright info from the comment at the beginning of the file.
61
    "copyright":  [
62
	// There can be multiple entries, one for each co-holder of the
63
	// copyright.
64
	{
65
	    // There can also be multiple years, like ["2021","2023-2024"].
66
	    "years": ["2021"],
67 5 koszko
	    // Name of the copyright holder. Depending on the situation it can
68 1 koszko
	    // be just the first name, name+surname, a company name, a
69
	    // pseudonym, etc.
70
	    "holder": "Wojtek Kosior"
71
	}
72
    ],
73
74
    // License of this json file. Identifier has to be known to Hydrilla. Can
75 6 koszko
    // be defined either in the same or another index.json file as a "license"
76 1 koszko
    // item. It is possible to specify license combinations, like:
77
    // [["Expat", "and", "Apache-2.0"], "or", "GPL-3.0-only"]
78
    // Alternatively, "auto" can be used to make Hydrilla attempt to extract
79
    // copyright info from this file's SPDX license identifier.
80
    "licenses": "CC0-1.0",
81
82
    // Where this software/work initially comes from. In some cases (i.e. when
83 5 koszko
    // the developer of content is also the one who packages it for Hydrilla)
84 1 koszko
    // this might be the same as "package_url".
85
    "upstream_url": "https://git.koszko.org/pydrilla/tree/example_content/hello",
86
87 5 koszko
    // Where sources for the packaging of this content can be found.
88
    "package_url": "https://git.koszko.org/pydrilla/tree/example_content/hello",
89
90
    // Additional "comment" field can be used if needed.
91 1 koszko
    // "comment": ""
92
93
    // List of actual site resources, pattern->payload mappings and licenses.
94
    // Each of them is represented by an object. Meta-sites and replacement site
95 6 koszko
    // interfaces will also belong here once they get implemented.
96 1 koszko
    "definitions": [
97
	{
98
	    // Value of "type" can currently be one of: "resource", "license"
99
	    // and "mapping". The one we have here, "resource", defines a list
100
	    // of injectable scripts that can be used as a payload or as a
101
	    // dependency of another "resource". In the future CSS style sheets
102
	    // and WASM modules will also be composite parts of a "resource" as
103
	    // scripts are now.
104
	    "type": "resource",
105 3 koszko
106
	    // Used when referring to this resource in "dependencies" list of
107
	    // another resource or in "payload" field of a mapping. Should
108
	    // be consize and can only use a restricted set of characters. It
109
	    // has to match: [-0-9a-zA-Z]
110 1 koszko
	    "identifier": "helloapple",
111 3 koszko
112
	    // "long_name" should be used to specify a user-friendly alternative
113
	    // to an identifier. It should not collide with a long name of some
114
	    // resource with a different uuid. However, it can change in-between
115
	    // versions of the same resource and is allowed to contain arbitrary
116
	    // unicode characters (within reason!).
117
	    "long_name": "Hello Apple",
118 1 koszko
119
	    // Different versions of the same resource can be defined in
120 3 koszko
	    // separate index.json files. This makes it easy to accidently cause
121
	    // an identifier clash. To help detect it, we require that each
122
	    // resource has a uuid associated with it. Attempt to define
123 1 koszko
	    // multiple resources with the same identifier and different uuids
124 3 koszko
	    // will result in an error being reported. Defining multiple
125 1 koszko
	    // resources with different identifiers and the same uuid is
126
	    // disallowed for now (it may be later permitted if we consider it
127
	    // good for some use-case).
128
	    "uuid": "a6754dcb-58d8-4b7a-a245-24fd7ad4cd68",
129
130
	    // "old_uuids" field can be used to indicate that some specific
131
	    // resource identifier collision is allowed, for example when some
132
	    // resource (e.g. a javascript library) changes its versioning
133
	    // schema. All definitions with one of the old uuids will be treated
134 3 koszko
	    // as less up-to-date versions, overriding the "version" field
135 4 koszko
	    // values comparison result.
136 1 koszko
	    "old_uuids": ["ad38dc5e-30b7-492d-9290-6c3ca658f1f3"],
137
138 7 koszko
	    // Version should match the upstream version of the resource (e.g. a
139
	    // version of javascript library). Revision number starts as 1 for
140
	    // each new resource version and gets incremented by 1 each time a
141
	    // modification to the packaging of this version is done.
142
	    "version": [2021, 11, 10],
143
	    // Specifying no revision is the same as specifying:
144
	    // "revision": 1,
145 1 koszko
146
	    // A short, meaningful description of what the resource is and/or
147
	    // what it does.
148
	    "description": "greets an apple",
149
150
	    // If needed, a "comment" field can be added to provide some
151
	    // additional information.
152
	    // "comment": "this resource something something",
153
154
	    // One should specify the copyright and licensing terms of the
155
	    // entire package. The format is the same as when specifying these
156
	    // for the index.json file, except "auto" cannot be used.
157
	    "copyright": [{"years": ["2021"], "holder": "Wojtek Kosior"}],
158
	    "licenses": "CC0-1.0",
159
160
	    // Resource's "dependencies" array shall contain names of other
161
	    // resources that (in case of scripts at least) should get evaluated
162
	    // on a page before this resource's own scripts.
163
	    "dependencies": ["hello-message"],
164
165
	    // Array of javascript files that belong to this resource.
166
	    "scripts": [
167
		{
168
		    // Script name. It should also be a valid file path.
169
		    "name": "hello.js",
170 2 koszko
		    // Copyright and license info of a script file can be
171
		    // specified using the same format as in the case of the
172
		    // index.json file itself. If "copyright" or "license" is
173 1 koszko
		    // not provided, Hydrilla assumes it to be the same as the
174
		    // value specified for the resource itself.
175
		    "copyright": "auto",
176
		    "licenses":  "auto"
177
		}, {
178
		    "name":   "bye.js"
179
		}
180
	    ]
181
	}, {
182 3 koszko
	    "type":       "resource",
183
	    "identifier": "hello-message",
184
	    "long_name":  "Hello Message",
185 2 koszko
	    "uuid":       "1ec36229-298c-4b35-8105-c4f2e1b9811e",
186
	    // If "old_uuids" is empty, it can as well be omitted.
187 3 koszko
	    // "old_uuids": [],
188 7 koszko
	    "version":     [2021, 11, 10],
189
	    "revision":    2,
190 1 koszko
	    "description": "define messages for saying hello and bye",
191
	    "copyright":   [{"years": ["2021"], "holder": "Wojtek Kosior"}],
192
	    "licenses":    "CC0-1.0",
193
	    // If "dependencies" is empty, it can also be omitted.
194
	    // "dependencies": [],
195
	    "scripts": [{"name": "message.js"}]
196
	}, {
197
	    "type": "mapping",
198
199
	    // Has similar function to resource's identifier. Should be consize
200 3 koszko
	    // and can only use a restricted set of characters. It has to match:
201
	    // [-0-9a-zA-Z]
202
	    // It can be the same as some resource identifier (those are
203
	    // different entities and are treated separately).
204
	    "identifier": "helloapple",
205
206 1 koszko
	    // "long name", "uuid" and "old_uuids" have the same meaning as in
207 7 koszko
	    // the case of resources. Uuids of a resource and a mapping can
208
	    // technically be the same, but it is recommended to avoid even this
209
	    // kind of repetition.
210 1 koszko
	    "long_name": "Hello Apple",
211
	    "uuid": "54d23bba-472e-42f5-9194-eaa24c0e3ee7",
212 4 koszko
	    "old_uuids": ["0525824d-f6e2-4ee2-8ac6-401e9dc79cdf"],
213
214
	    // "version" differs from its counterpart in resource in that it has
215 7 koszko
	    // no accompanying revision number.
216
	    "version": [2021, 11, 10],
217 1 koszko
218
	    // A short, meaningful description of what the mapping does.
219
	    "description": "causes apple to get greeted on Hydrillabugs issue tracker",
220
221
	    // A comment, if necessary.
222
	    // "comment": "blah blah because bleh"
223
224
	    // The "injections" array specifies, which payloads are to be
225
	    // applied to which URLs.
226
	    "injctions": [
227
		{
228
		    // Should be a valid Haketilo URL pattern.
229
		    "pattern": "https://hydrillabugs.koszko.org/***",
230
		    // Should be the name of an existing resource. The resource
231
		    // may, but doesn't have to, be defined in the same
232
		    // index.json file.
233
		    "payload": "helloapple"
234
		},
235
		// More associations may follow.
236
		{
237
		    "pattern": "https://hachettebugs.koszko.org/***",
238
		    "payload": "helloapple"
239
		}
240
	    ]
241
	}, {
242
	    "type": "license",
243
244
	    // Will be used to refer to this license in other places. Should
245 6 koszko
	    // match the SPDX identifier if possible (despite that, please use
246
	    // "Expat" instead of "MIT" where possible). Unlike other definition
247
	    // types, "license" does not allow uuids to be used to avoid license
248
	    // id clashes. Any attempt to define multiple licenses with the same
249 1 koszko
	    // id will result in an error being reported.
250
	    "identifier": "CC0-1.0",
251
252
	    // This long name must also be unique among all license definitions.
253
	    "long_name": "Creative Commons Zero v1.0 Universal",
254
255
	    "legal_text": [
256
		// Legal text can be available in multiple forms. Usually just
257
		// plain .txt file is enough, though.
258
		{
259
		    // "format" should match an agreed-upon MIME type if
260
		    // possible.
261
		    "format": "text/plain",
262
		    // Value of "file" should be a path relative to the
263
		    // directory of index.json file.
264
		    "file":   "cc0.txt"
265
		}
266
		// If a markdown version of CC0 was provided, we could add this:
267
		// {
268
		//     "format": "text/markdown",
269
		//     "file": "cc0.md"
270
		// }
271
	    ]
272
273
	    // If needed, a "comment" field can be added to clarify something.
274
	    // For example, when definind "Expat" license we could add:
275
	    //
276
	    // "comment": "Expat license is the most common form of the license often called \"MIT\". Many other forms of \"MIT\" license exist. Here the name \"Expat\" is used to avoid ambiguity."
277
278
	    // If applicable, a "notice" can be included. It shall then be a
279
	    // path (relative to index.json) to a plain text file with that
280
	    // notice.
281
	    //
282
	    // "notice": "license-notice.txt"
283
	    //
284
	    // This is needed for example in case of GNU licenses (both with and
285
	    // without exceptions). For example,
286
	    // "GPL-3.0-or-later-with-html-exception" could have the following
287
	    // in its notice file:
288
	    //
289
	    // This program is free software: you can redistribute it and/or
290
	    // modify it under the terms of the GNU General Public License as
291
	    // published by the Free Software Foundation, either version 3 of
292
	    // the License, or (at your option) any later version.
293
	    //
294
	    // This program is distributed in the hope that it will be useful,
295
	    // but WITHOUT ANY WARRANTY; without even the implied warranty of
296
	    // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
297
	    // GNU General Public License for more details.
298
	    //
299
	    // As a special exception to the GPL, any HTML file which merely
300
	    // makes function calls to this code, and for that purpose
301
	    // includes it by reference shall be deemed a separate work for
302
	    // copyright law purposes.  If you modify this code, you may extend
303
	    // this exception to your version of the code, but you are not
304
	    // obligated to do so.  If you do not wish to do so, delete this
305
	    // exception statement from your version.
306
	    //
307
	    // You should have received a copy of the GNU General Public License
308
	    // along with this program.  If not, see
309
	    // <https://www.gnu.org/licenses/>.
310
	}
311
    ]
312
}
313
```