# Filebase
A desktop window over a directory of [Slipcase](https://slipcaseformat.org) containers. Point it at a folder, ask a question in [SlipQL](https://github.com/excelano/slipql), and the containers that answer come back as rows — one row per container, one column per metadata key. Select a row and the container's payload and its full metadata are beside it; press Open and the payload goes to whatever the system opens that kind of file with.
It reads. It never writes a container, and there is no Save in it: [Slipcase Desktop](https://github.com/excelano/slipcase-desktop) is the editor, and [Tommy Flyleaf](https://github.com/excelano/flyleaf) is the metadata editor both of them draw with.
## Why
A container carries a TOML document describing its payload, and that description travels with the file. Once a folder holds a few hundred of them, the question stops being *what is in this file* and becomes *which of these files say this* — and a file manager cannot answer it, because to a file manager they are all ZIP archives with the same icon.
Unpacking every container to find out, or keeping an index that goes stale the moment somebody copies a file in, both defeat the point of metadata that lives with the document. Filebase keeps no index and no state: every query is a fresh scan, so the answer is what is on disk now, and the metadata is read in place without unpacking a payload.
## The query
The language is SlipQL, and Filebase embeds the same crate the `slipql` command runs, rather than reimplementing it — which is why the language was written first. Its `GRAMMAR.md` is the reference, and the short version is that clauses come from SQL and literals come from TOML:
```text
select @path, title, governance.owner where status = "draft" or tags contains "legal"
```
The chosen folder supplies `from`, so a query in the window can leave it out. Tick **recursive** to descend into subdirectories; a scan does not descend unless asked. `select *` gives `@path` and then every metadata key across the containers that answered, which is the quickest way to learn what a folder has to query against.
A key a container does not have renders as an empty cell rather than failing the query, because metadata keys are ad hoc by design. A file that cannot be read is skipped and reported under the rows, and so is a comparison that crossed types — `pages > 10` against a container whose `pages` is a word is neither true nor false, and the count of them is on screen rather than swallowed.
## The window
The folder and the query are at the top, the rows fill the window, and the selected container is on the right: its payload's name and size, a button that hands the payload to the system, and its metadata as a tree. Rows appear as the scan finds them rather than when it finishes, and starting another query stops the one before it.
A folder can also be named on the command line, which is what a file manager passes when it is asked to open a folder with this. There are no flags: `slipql` is the command-line interface, over the same engine.
## Building
`cargo build --release`. It needs a Rust toolchain and nothing else — nothing here compiles C, and `Cargo.toml` says what each dependency is for and what was measured about it.
## License
MIT. See [LICENSE](LICENSE).