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 (and closely adjacent) Features

In no particular order:

• vfile.mhash field: this was added sometime after the lib took a break and needs to be populated/handled by the lib code.

• Port over checkout/repo fingerprint: this allows detection of when a checkout's repo has been replaced by one with different RIDs. See fossil's vfile.c:vfile_rid_renumbering_event().

• 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 tickets: the library can read and write them but they cannot yet be crosslinked. Currently, depending on a context-dependent flag, it may error out if it tries to crosslink one or it may silently skip over it.

• 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.

• Stash support. First requires merge support.

• Unversioned files should be trivial to do.

• Update search index for new content. The crosslinking steps currently do not do this, pending addition of the search infrastructure. (Code grep keyword: search_doc_touch)

Security-relevant

But not otherwise SCM-relevant...

• Port over db_unprotect() and db_protect_pop() APIs, which allow a db to effectively be made read-only except for limited windows where specific sections of it needs to be writable. Related: db.c:db_top_autorizer().

Non-SCM TODOs

• Add SPDX-style license attribution to all source files.

• Header file restructuring. The current separation of the APIs into many include/fossil-scm/*.h files is somewhat confusing. The initial intent was to keep my low-end development system of the time from choking on syntax highlighting on one large file, but those days are largely behind me. It may make sense to combine those into 1 public API file, 1 internal API file, and the auto-generated config file(s).

• Stop using char as booleans. This tree historically uses char type for booleans. We should use int instead or switch to C99, which has a bool type.

Maybe TODO

• Undo support.

• Symlinks. i have always disagreed with the addition of symlink support into fossil: platform-specific constructs simply have no place in the core of any SCM. For platforms which don't support symlinks, fossil stores/manages them as plain text files with a single line holding the name of the referenced file. This is very likely the route the library will take, especially since the hassles symlink handling caused fossil in late 2020 (long story). Probably the only way the library will support proper symlinks is if someone who uses that feature adds it.

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.