Roger, Clearly not every feature that has found its way into SQLite is useful to "the majority" of the user base, but I will accept the core philosophical position here as not unreasonable--a requested feature that benefits very few use-cases might well be placed lower on the to-do list than one everybody wants. And yet there are some very simple and lightweight functions that are easy to add to the core without fear of bloat. Something that can be knocked out in a half-hour might get a higher a priority than something everyone desires but is far more involved, and could take many man-weeks to get right.
You write: "There is no reason why you can't talk to the library simultaneously via ADO.net as well as via the SQLite API directly." It is not always possible to do what you have suggested. Some application runtime environments are "sandboxed" and do not give the developer the freedom to call an external library, or to add UDFs to their implementation of SQLite. If the functionality is not present in the core database, the developer could be out of luck when programming in such environments. Of course I understand it is not the fault of the SQLite architects or its author when a runtime environment restricts what can be done with SQLite. I'm only asking that such environments be kept in mind as one of the criteria when assigning a priority to a requested feature. @Sam: I understand the open-source and TCL origins of SQLite, but the essence of something does not always come out of its origins; destiny and destination can shape things too. Who could have known, way back when, that SQLite would influence the direction of the web? Regards Tim Romano Swarthmore PA On Sat, Jul 24, 2010 at 10:57 AM, Roger Binns <rog...@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/24/2010 04:42 AM, Tim Romano wrote: > > Quite a few users of SQLite these days are not wrapping > > the SQLite libraries in their own client app but are communicating with > the > > database via a bridge as if it were a remote server engine. > > Yes, but the SQLite library is still local within the process in that case. > There is no reason why you can't talk to the library simultaneously via > ADO.net as well as via the SQLite API directly. (If you are using pragmas > then you are already having SQLite specific code.) > > > Your opposition to my request several months ago for a raw reverse > > function was colored in this way. You did not acknowledge at the time > that a > > raw-reversed (and hence possibly malformed) sequence of unicode > codepoints > > could give middleware the hiccups, and insisted that it this reversal be > > done "in the application". > > SQLite doesn't have a reverse function as shipped, and so is not the one > creating invalid data. I'll happily acknowledge that malformed Unicode is > a > bad thing under all circumstances. > > The license of SQLite allows you to do anything you want with it. (The > trademark prevents you calling the result 'SQLite'.) You can add, change, > delete etc anything. You can redistribute the changes or keep them secret. > You can charge for them. > > What many of these requests amount to is wanting someone else to make a > change (typically the SQLite developers) and for the change to be > distributed as part of SQLite. The bar for that is *considerably* higher > and you would need to demonstrate the value to the majority of the user > base > and why the extensive existing mechanisms (extensions, the SQLite API etc) > are not sufficient. > > The "opposition" is pointing out that bar, and suggesting alternate > approaches. (Note I am not a core developer nor do I speak for them but > have been around long enough to observe what they usually do.) > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxK/2kACgkQmOOfHg372QSyrgCfaMDkggv6PObyADTR+Cfdz68E > b3YAnj/ihpG0DVet4Y/5Z/RlSDs9QuWR > =K1/M > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
