On 11 janv. 2011, at 13:15, Richard Hipp wrote:

> On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps 
> <j...@q-e-d.org>wrote:
> 
>> 
>> My rationale is that either it's technically or economically feasible
>> for the offending applications' developpers to change their code to use
>> the library correctly (and that doesn't seem to be the case), OR very
>> simply avoid upgrading to the new SQLite versions.  I don't get what
>> good reason they had to switch to new SQLite versions.
>> 
> 
> 
> I don't think I explained the problem clearly.
> 
> The proposed change is for the benefit of the applications customers, not
> the application developers.
> 
> An end user (think: your mom) wants to upgrade her smartphone to the latest
> OS release.  That new OS release includes the latest shared library for
> SQLite.  But in so doing, some percentage of the apps she has downloaded
> cease to work.  Sure, the problem really is that the apps were incorrectly
> coded.  But does your mom really care about that?  They worked before.  Do
> we really want thousand, perhaps millions, of moms screaming that SQLite
> broke their phone when they upgraded?

moms won't know that SQLite is involved. They can blame either the crashing app 
or the OS. And they will probably blame the app. An OS upgrade almost always 
lead to incompatibilities for some app, for a number of reasons. This is the 
least of the reasons for app developers to update their app when an OS is 
upgraded. There is absolutely no reason to think that the app cannot be revised 
(fixed) at this point in time (or any other point in time). Unless the software 
is abandonware. Then, a bug in its SQLite code is the least of mom's problem.

Don't encumber SQLite with workarounds and special cases to cater to bugs in 
client software. If so many moms are using it, the software developers will 
have enough incentives to fix their problems on their side.

Making the API more complex to use or document increases the cognitive load of 
*all* users of SQLite, for the sake of a few programmers who don't bother. 
Don't do it.

If anything, make sure to crash early and often when the API is misused. In 
that way, the client software can't avoid noticing the bug and fixing it.

Jean-Denis

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to