On May 31, 2018, at 6:32 PM, Roger Binns <rog...@rogerbinns.com> wrote: > > On 31/05/18 10:15, Richard Hipp wrote: >> Size is still important. But having useful features is important too. >> I'm continuing to work to find the right balance between these >> competing goals. > > A pattern used in other projects is to have standard downloads, as well > as custom ones.
Your jQuery example later on doesn’t much apply here, for several reasons: 1. JavaScript is a dynamic language, while C is a statically-compiled language. That means that all of the symbols needed to link the program need to be available at link time in order to produce a binary. To achieve that with C, you’d have to do things like create mock modules that export an API but don’t implement it, merely to placate the linker. Contrast a language like JavaScript, where you can ship a program that has calls to functions that don’t exist, and as long as you continue to not call those functions, the JS VM won’t balk. 2. There are ways around this with C, such as with the plugin pattern — which is in fact already being used in SQLite’s VFS layer — but it carries an indirection overhead. jQuery is a bad exemplar here because it’s a solution for implementing user-facing actions, which means that as long as each group of actions implemented using it take under 100 ms or so, it’s fast enough. For SQLite, though, adding layers of abstraction merely for the programmer’s convenience means slowing it down materially, which can turn a viable solution into failure. Some sage once opined that any problem in computer science can be solved by adding another layer of abstraction, but there is one that can’t: “The software is too slow, and we’re unwilling to buy more hardware.” 3. SQLite already has a way to generate multiple versions of the source code in a programmatic way: #ifdefs. That’s precisely what the C preprocessor does. JavaScript has no equivalent mechanism, so someone had to go an factor jQuery into modules by hand and rely on the user to provide the correct subset of modules needed by their software. One could write a variant of cpp that would run on the sqlite3.c amalgamation to produce predigested subsets without bringing in all of the #includes, but all that’s really needed here are curated sets of -DSQLITE_* flags, since then the end user can use them with the C preprocessor they already have. I’ve a feeling that I’m missing more reasons, but those will suffice. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
