This PR adds a CLI interface to fff. After talking with @dmtrKovalenko, we decided that the best architecture is to have an fff daemon run in the background to keep the index hot. The command that the user interacts with is fff-rg, which talks to this daemon.

Before we proceed, it's worth looking at the architecture diagram here:

flowchart LR
 subgraph fff-rg
 rg-searcher
 fffd-searcher
 end
 subgraph fff-daemon
 query-service
 subgraph session-pool
 session-1
 session-2
 end
 query-service --> session-1
 query-service --> session-2
 end
 rg-bin[[rg]]
 fffd-searcher <-->|unix sock|query-service
 rg-searcher <-->|subproc| rg-bin

Let's walk over each component:

fff-rg

fff-rg can search either through talking through the fff-daemon, or through shelling to rg. It picks the fff-daemon if it believes to be working within a git repo. Otherwise, it will fall back to rg, and if the user doesn't have it installed, it will abort.

The core reasoning for this is that holding an fff-daemon alive for directories that don't need to be indexed makes no sense, as you'll hold a very large amount of RAM in memory for an effectively one-off search.

fff-daemon

The fff-daemon holds within it a query-service. This query-service is responsible for accepting connections from new clients and then passing the request down to the session-pool.

The session-pool is a pool of "active" sessions, ie. active git repositories for which we have an fff index in memory. A couple notable facts:

• The session pool automatically reaps old sessions. If a search hasn't been performed for a while on a directory, chances are the user no longer cares for it, so we should evict it.
• The session pool has an LRU policy which means that if we're out of available pool slots, we'll kick out some unused and old session in favor of creating a new one.

IPC protocol

I spent a good bit of time thinking through how best to handle the IPC protocol, and the epiphany I had is that we don't actually need to shuttle results between the daemon and the client. There may be hundreds, if not thousands of strings we'd need to copy, so if we can avoid it, that would be awesome.

On UNIX, you can pass file descriptors by using SCM_RIGHTS between processes. This enables us to take the stdout fd of the client, pass it to the daemon, and have the daemon directly write to the client's stdout. Neat!

The downside of this approach is that SCM_RIGHTS requires a unix domain socket, which means that passing the fd needs to happen over that. I evaluated:

• Adding a sidecar iceoryx2 for all the other message passing, but ultimately I couldn't justify the maintenance burden. There's a ton of complexity added in figuring synchronizing the req-rep flow of the mmaped iceoryx2 channels and the req-rep of the fd transfer, so it made no sense.
• Just having the req-rep flow between the client and the daemon live on the UDS (unix domain socket), which is ultimately what I landed on.

This lives in the crates/cli/fff-ipc-domain crate.

Holes in the implementation

• Tests are quite lackluster. I added some testing, but it's quite weak.
• There are a couple open questions I've left as comments on this PR.
• The LRU logic could be separated out to a separate container which is responsible for automatic eviction.