# Things for not-forking to consider next

## Features, bugs and improvements

* improve the example recipes. lumoSQL is great, but need some diverse illustrations
* implement `not-fork lint` that checks recipes (see also grammar in next section). This will save some grief from human errors
* revisit the comparator. Now we know it is good (so that people wrote papers about it not knowing it already existed in not-forking) perhaps we can think about
  families of versions. Different packaging ecosystems have their own schemes so we could just say "we're using python-style" even if we are actually using
  Go. That way we can give intercal (for example) its own scheme within which it can go nuts. There's nothing like this in the literature... it's somewhat flattering to
  be compared to PURL and libversion but we do it better.
* Improve fragment-patch, because in 100-200 lines we should be able to replace the unreliable, undocumented patch(1) specification and algorithm for the
  specific case of applying our kind of fragments (which are anchored by regex's , making them more reliable to start with).
* Make cache concurrent. The not-forking cache is a major part of its benefit for non-trivial codebases with a few variants and/or upstreams. At present
  concurrent access within a single controlled run is difficult-to-impossible, and concurrency between multiple runs is definitely impossible.
* Make cache robust to failures of `fossil revert`, or `git checkout` failures on a dirty tree.
* Make the offline cache just as good/native as the online. At present 
* Make it possible to seed a cache (no matter whether offline or online) from a given URL. Especially useful for when the URL is `file://my/directory/repo`,
  letting us seed from a normal `git clone` or `fossil clone` tree. Some likely `not-forking` candidate users have huge trees.
* not-fork version_filter cannot cleanly express "exclude the 1.x line" against the LumoSQL LMDB recipe. LumoSQL uses a hack, `< 1.0-alpha` in upstream.conf to
  exploit the not-forking convention that pre-release suffixes sort below the bare version: `1.0-alpha` is the lowest known pre-release token, so comparing against it
  excludes everything else including any 1.x releases. This is a not-fork bug but not urgent for LumoSQL now this hack is in place.

## Strategic stuff

This should probably use some of the vocabulary from the literature, now we know that eg Conradi & Westfechtel have given names to these concepts after we
implemented them

* (easy) Create a schema for the lockfile (eg TOML or similar), which records a snapshot in time of what the current answer to "latest 3.47.x release of
  SQLite" is, which will be 'commit abcd12345'. This will mean other tooling can integrate with not-forking straight away. This is the reproducible bit
  from the human intentional bit in the recipe.
* (easy) Create 'not-fork hash' command or similar which gives a content addressable identifier for the tuple (recipe + lockfile + upstream commit
  ID), or something like that, at which point we can compute results without building them, and we have also implemented Nix.
* Create a grammar for Claudio's not-forking specification document
* Create a very simple second implementation of the grammar that will do some basic operations to show that the grammar appears to work and it has at least two
  users

## Not really not-forking

* When run on many VMs and behind many kinds of strict proxies, Fossil fails while git sails. Unforunately this is a problem when populating a giant
  cache. The following 2 line patch to Fossil solves the problem. Maybe it should be discussed upstream:

  --- a/src/http.c
  +++ b/src/http.c
  @@ -153,8 +153,9 @@
     }else{
       zPath = g.url.path;
     }
  -  blob_appendf(pHdr, "%s %s HTTP/1.0\r\n",
  +  blob_appendf(pHdr, "%s %s HTTP/1.1\r\n",
                  nPayload>0 ? "POST" : "GET", zPath);
  +  blob_appendf(pHdr, "Connection: close\r\n");
     if( g.url.proxyAuth ){
       blob_appendf(pHdr, "Proxy-Authorization: %s\r\n", g.url.proxyAuth);
     }

  This is just embarassing. Especially when we can't even fetch sqlite from sqlite.org, which is seemingly the most canonical task for Fossil.

