> > Actually, it's everyone using a language other than C/C++, plus a > > proportion of those too. I use C#, but if you want to call Sqlite from > > Java, Python, etc or even some generic C/C++ app that supports > > plug-ins, then at some point there is a DLL > > How does that follow? Any higher-than-C language has its own binding system, > and SQLite is a module of some kind, where the C library is wrapped in the > module that exposes its own API. If the module statically links in > libsqlite3.a -- as, arguably, it should -- then there's no version ambiguity, > no DLL, and no chance of conflict.
Then I think you misunderstood. You dropped in a 'module' without mentioning that this would have to be written in C/C++. There is absolutely no way to call Sqlite statically from any language other than C (or one of the rare languages that implement a C-compatible ABI). So: [Here HLL means Java/C#/Python/Perl/etc] HLL -> Sqlite, DLL HLL -> C-module dynamically linked -> Sqlite, DLL HLL -> C-module statically linked -> Sqlite, no DLL The reason this matters is that every 'module' injects its own world view. If you want to call Sqlite from a HLL and make it look like other databases then you use a 'module'. But if you want to call Sqlite from a HLL and see exactly the same API that libpq exposes then you call the libpq DLL. This is what I do in Andl. I need to control the communications channel in ways that your 'modules' do not allow, so I use the libpq DLL. Regards David M Bennett FACS Andl - A New Database Language - andl.org
