|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
# libfossil Notable TODOs
This page gives a high-level overview of the notable TODOs, or perceived TODOs, as well as non-TODOs (topics/APIs which are either out of scope or are way, way down the line).
# Core SCM Features
In no particular order:
- **Merging**: to port from fossil.
- **Rebuild**: this feature exercises almost every major SCM feature of the framework except for merging and synchronization. Similarly, deconstruct/reconstruct might be useful for exercising the library.
- **Cross-linking of forum posts**: they can be ready by the library but cannot yet be crosslinked. Related: add a context-specific flag which tells crosslinking to simply skip these, rather than fail.
- **Double-check crosslinking of other types** and make sure that we are not missing newly-added features.
- **Bring the configuration-related state up to date.** The infrastructure is there but the exact list of fossil-supported properties is lagging behind by several years.
# Remote Synchronization
- This will be implemented in terms of abstract streaming APIs, very possibly the ones the library already uses for the majority of its file I/O and abstracting output streaming (e.g. it uses an abstract output stream for diff output, rather than writing directly to a buffer).
- This will almost certainly be one of the last major features.
# Wiki Parsing and Rendering
- This set of features hovers *right on the edge* of out-of-scope for the core libfossil. Rendering is necessarily output-format-specific and the library has no business defining such outputs. Also...
- The fossil implementations of these are not written with port-friendliness in mind, so a complete reimplementation would possibly be necessary.
- In order to support near-arbitrary applications the wiki parsers need to be implemented in such a way that clients can customize (via hooks/callbacks) how links/references are generated.
- The venerable Fossil Wiki format has the lowest priority. In practice markdown has easily taken the lead, and only old (pre-markdown) docs tend to be maintained in that format.
- Alternately, rather than render in the conventional sense, we could potentially output the parsed data in a high-level format (similar to an AST) off of which to base the concrete renderers. That still requires writing per-format parsers, though, which is a drag.
# Non-TODOs
- **Any and all UI-related elements**, including HTML, CSS, and JavaScript. The library will enable such applications but will not provide, e.g., an HTML framework beyond *perhaps* (maybe) wiki rendering.
- **Scripting of tickets**. There are no current plans to 100% mimic fossil's th1 scripting of tickets. Fossil's use of TH1 was one of convenience, not long-term practicality. The library itself will have no "official" scripting language, but is designed specifically to make tying it to scripting engines relatively straightforward.
|