Documentation: list of addons and extras
Twice in the last month I've looked for something in SQLite which is not mentioned in the API documentation, because it is an extra program, or a rarely used addon. Having read this forum (or the email list) for years, I know roughly what the feature is called, or a word that is probably mentioned in the documentation for it. I can use the website's search features to find that word.
But many newer users of SQLite may be looking for useful or interesting extensions/addons and not have that advantage. So I went looking for a web page which mentions all the extras. And I couldn't find one. A good source is to use
and reveal both 'extensions' and 'tools'. This gets me json1, the archiver, Android bindings, and FTS5. But not the Checksum shim. And the System.Data.SQLite bindings are listed in Programming Interfaces. It also doesn't mention the backup API, because that's part of the C API, yet people can miss it if they don't happen to be looking through the complete list of API function calls. And why would anyone do that when looking for what feels like an addon, not a basic SQLite feature ?
I'm thinking there could be useful things developed and supported by the SQLite team, which users would find if there was a list all on one page. Am I missing that such a list exists ? Or just being silly ?
I've considered the extension sources to be the documentation you find missing. The files there are generally commented to show purpose and usage.
As for appearance in the main SQLite library documentation, I always figured the extensions are not part of the library and serve as examples of the extension API or tools for internal use.
Maybe some expansion of the README.md files in the extension subdirectories would suffice for the purposes you envision.
If there is silliness in your idea, I would only assign such to the implication that the library documentation should cover extensions.
I think extensions are covered well, but they are a minority of what the people I am picturing want. And those people won't be looking at source code at that point, because they'd have to search the whole codebase, because they don't know what they're looking for yet.
My imagined users have an idea in their head of 'copy an active database' or 'quick word search' or 'interface with System.Data' or 'difference between two databases'. They don't know the name SQLite uses for it, or whether they're looking for API calls, a loadable library, a utility program, or a VFS. Just what they want done.
The page I'm thinking ofl would be "Here are links to 40 supported features you wouldn't stumble on when figuring out basic write/read/find.". And it would links to all of these
- what unicode support is there ?
- fast text search
- System.Data and Android bindings
- the backup APi
- the checksum shim
- comparing two databases
- SQLite Database Analyzer
- json support
even though they are different kinds of things. Because the person looking for features doesn't know enough to guess whether something is a VFS or a utility program. Someone who has just got into SQLite runs their eye down that page of links once. They might seize on something immediately, or a year later come up with a new requirement and remember that SQLite does it because they read it somewhere.