Because this list supports many different things, not just SQLite downloaded from sqlite.org, maybe I'm off target with my interpretation of these wishlists.
I'm not arguing about pros and cons of shared libraries directly. My comments were made from a tired guy who started the day early, was busy being active with family, and then finished late, so yeah, it was a bit confusing. For the record, *I* personally prefer trying to get all essential resources built directly into my final output (For SQLite, default database structures, SQLite strings, and maybe that one day, SQLite itself), that way I'm in control of what the application does, and have no reliance on a 3rd party update to a resource file that breaks my code. That is just my preference, and old school or not, I prefer working software, not software that might work after MySQL updates and breaks a resource I require when my application doesn't touch MySQL, or when a user deletes a critical file my application requires and claims they didn't do anything (Other than sort all .EXE into c:\EXE and trashed as many DLL files since they don't RUN properly -- Thank you BOFH for bringing that situation to mind). I've never had 100% success on a fully independent database driven application (SQLite or not), and that is perfectly OK. That doesn't mean I'd like to strive for that one day. The thought of my recoding SQLite C to Pascal is only a pipe dream, and only means that I can remove another external dependency not controlled by me, and it'd be kind of fun, AND I might finally understand the C code well enough to contribute, *AND* it'd be my first application that'd let me read and write to a foreign binary data structure successfully. If I'm bored, I might do it. More likely to shoot my foot off, or some jazz like that though. What I'm arguing for is that SQLite stays as is (Allowing for enhancements, of course), and any language out in the field that would LIKE to include SQLite should conform to SQLites calling conventions, at least to the basics of calling conventions for prepare, or connect, or what have you. Obviously, making BASH scripts directly support SQLite is kind of an oddball request, but if it were ever to be, it should be on the BASH language developers to conform to what SQLite provides, not ask that SQLite abides by BASHs rules and regulations. The reason for this is that SQLite should NEVER conform to everyone elses standards because everyone believes their standards are first and foremost and to hell with everyone else. There is no global standard for all language calling conventions, and some of the wishlists I've seen are asking that SQLite bend to their views, which is exactly what has me on edge. A wrapper should be used for convenience or internal standardization, not the pendulum in a lever (Otherwise you just have a stick, or a bunch of unhappy kids who can't play on the teeter-totter). A wrapper should take whatever the language provides and either enhance it, or, rename functions that makes more sense to the developers. I'm in no way arguing that the sqlite3.dll (and equivalent) should be embedded into every language compiler so it is transparent and shipped with the executable with no reliance on a shared resource. That purely is my deal, my internal wish list, and NOT something I'd ever DREAM of asking the SQLite devs to conform to. I'm arguing that any language that wants to provide access to SQLite should have some rudimentary built in commands that permit access to the shared resources, and then the Perl, "R", Pascal, Delphi, PHP, and DOT-NET developers just need to write their wrappers against what the language developers provide. Again, I'm not arguing that the DLL/SO/whatever ends up in the final build of the executable, but just that the language compiler or interpreter has the fundamental functionality to allow for simple wrappers to exist without having to go to strangers. To be honest, I've never heard of the language "R", so I don't know what it is, how "high" that high-level is, or even what its syntax is like, whether it is a compiled language or if it is JIT. So the comments of (And I'm SUPER exaggerating with this) *"I use this language called 'Ego' which is far superior than any other language, and the way SQLite interacts with my language sucks. I'd like to see SQLite allow me to use SEL instead of SELECT because I use a lot of selects in negative-endian, reverse notation, double-width-unicode strings only my language supports, so I'd be saving LOTS of space!"* is what is kind of grinding my wooden gears. On Fri, Jan 8, 2016 at 2:51 AM, Darren Duncan <darren at darrenduncan.net> wrote: > Stephen, > > What you are arguing for (no shared libraries) is bad old days where one > had to recompile their programming language to add support for a DBMS, > rather than the DBMS support being a separately installable library that > one could choose to install or not or upgrade semi-independently or not, or > choose to use an alternative or not. > > Sure, SQLite is public domain, but why should every language bundle it > into their core just because? There are lots of other useful libraries one > could make the same argument for. Bundling it can make sense if the > language core itself depends on SQLite or practically all of its users > would use it, but that's not usually the case. > > I should also point out that the standard Perl interface for SQLite, the > DBD::SQLite module, bundles the SQLite source with it, so installing that > Perl library gives you SQLite itself, there are no DLLs or dependence on > some system SQLite library, but Perl itself doesn't have this built-in nor > should it. > > In the Perl 4 days you had to recompile Perl to make a version that can > talk to a DBMS, eg "Oraperl", but thankfully with Perl 5 (1994 or so) we > did away with that. > > -- Darren Duncan > >
