On 30 Aug 2013, at 2:11pm, John McKown <john.archie.mck...@gmail.com> wrote:
> I know that sqlite is designed as an "embedded" SQL engine. But I am > curious if there is a specific reason to _not_ have a DLL/shared object. > The main reason I ask is that a DLL is required in order to create a sqlite > Java JDBC interface. The arguments against DLLs are not the normal arguments you see, they're governed by an unusual combination of four characteristics of SQLite: A) SQLite is very much liked, and a huge number of programs use it. B) SQLite is tiny. You don't waste much disk space by having lots of copies. C) There are frequent version updates to SQLite which introduce new facilities. D) SQLite is detailed and complicated, so updates sometimes break assumptions made by programmers. The assumption for a DLL is that the operating system would include a SQLite.DLL in a known place, and every programmer who wanted to use SQLite would have to use it. So let's see what would happen if you did that with SQLite. SQLite is used by various parts of the operating system and three other apps. A new SQLite feature comes along and a programmer wants to exploit it so either their installer updates any old SQLite.DLL it finds, or the program tests for the version of SQLite and tells the user to update. Between the two versions of SQLite an old bug was fixed or an assumption was changed, and suddenly one of the other apps -- a widely used standard app -- stops working. The publisher puts out a FAQ saying "This app is not compatible with versions of SQLite bigger than 3.7.1.8.". This means users have to choose between his app and that new one they want to install. Neither publisher wants to lose sales so they figure out some sort of dependency system for installers, or you have various DLLs named things like SQLite3709.DLL and SQLite3802.DLL and everyone needs to use a named version instead of just SQLite.DLL. It's all a horrible mess. Contrast this with the idea of every programmer including their own amalgamation code in their own program. The downside is that each of the app files is very slightly bigger. The upside is you don't need an installer to install your app, the apps don't have dependencies, and the apps don't have to include a test to see which version of SQLite they're running. Simpler for programmers, simpler for publishers, simpler for users. Everyone cheers. Now, agreed that this system doesn't work for .NET or for JDBC. But those are faults in .NET and JDBC, not in SQLite. SQLite is doing the job it was designed for, and doing it fine. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
