On Fri, Aug 30, 2013 at 1:37 PM, Simon Slavin <[email protected]> wrote:
> > On 30 Aug 2013, at 4:46pm, Jay A. Kreibich <[email protected]> wrote: > > > On Fri, Aug 30, 2013 at 03:41:18PM +0100, Simon Slavin scratched on the > wall: > > > >> 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. > > > > I'm not sure that last one is fair. Generally, the SQLite team makes > > a huge effort to avoid breaking backwards compatibility, both documented > > and assumed. There are a whole list of known bugs that will never get > > fixed because they might break existing applications. While there > > are some changes to the query optimizer that sometimes do odd things, > > overall this is a pretty poor reason. > > While I take your point there have been numerous examples in the last year > of what I would call 'assumptions made by programmers' which aren't obvious > bugs. For example the user who had a SELECT where a calculation was named > the same as a column which actually existed in the table, and one version > of SQLite did one thing, and another did the other. It was only possible > to identify one of them as a bug by detailed examination of a late version > of the SQL standard. Without that they were both arguably acceptable SQL. > > > For me, the biggest issue is A and B, combined with the fact that > > many applications that very heavily use and integrate SQLite often > > have a custom compile with specific extensions, default values, and > > features turned on or off. > > That's one I missed. Yes: very many compilation options, with none > obviously better than others. Therefore different people want different > object code. > > For me the biggest argument is that the SQLite dev team go to the effort > of making amalgamation source code available, which I think is wonderful. > But I wasn't brought up in the world of Windows programming where you > expect everything to be a DLL, and I can understand someone who was > wondering why anyone ever did anything but use the a 'standard' DLL. > > It's not that "everyone in Windows programming expects everything to be a DLL"; this is an overgeneralisation. After all, Java isn't exactly Windows-only code and we're not dealing with Win32, but with IBM zOS. However, think a bit on the problem of how you could compile in a native code object file into a program which runs inside a virtual machine. This is a problem with Python, Lua and Ruby, as well, although in Python and Lua's case we could create a C executable hosting the Python or Lua VM inside it and expose the SQLite API to it via extension methods. I don't know how embeddable Ruby is. At any rate, one cannot generally embed a JVM or CLR into a C program, so you're left with one mechanism, which is the very Unix-y dlopen()/dlclose()/dlsym() interface, or its Windows analogue, LoadLibrary()/FreeLibrary()/GetProcAddress()... > Simon. > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- In those days, in those distant days, in those nights, in those remote nights, in those years, in those distant years... - Gilgamesh, Enkidu and the Underworld _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
