>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?
Yes if the choice is the only one left, then I for one want zillions of users complaining worldwide! Software liability has to find its way someday. It has become too easy for major software vendors to release crap without care and consider that the next release will fix the most crying bugs/misfeatures. Now if it has been that common and easy to download and install a new whole OS, then how difficult is it to scan the smartphone at the same time for broken applications versions and push in fixed ones? Again, all those companies have plenty of resource for planing such a move and the incentive for the phone maker is to maintain a good reputation vs competition, for the OS maker to show that his OS can be kept up to date and still working fine and for the app supplier that he is careful and responsive to his customers. Taking up the responsability for this bug and changing SQLite for coping with incompetence will only open the avenue that every time a significant widespread application will prove buggy, then the author will be tempted to ask you to put in a specific workaround. I remind a post by Roger Binns (I believe) regarding the history of SMB/Samba and the awfull number of such "workarounds" that have cropped into it (to overcome bugs in protocols, in implementations and possibly in common big name applications) to such an extent that the whole stuff has become unmanageable and unreliable, which seems to be one of the main reasons why for instance SQLite can't be used over a network reliably. Again, and since installing a new OS version into smartphones has been that easy, why don't OS makers force download of a revised OS version including a specific SQLite version suited to the park? Even if I agree and understand that the proposed change has minor or zero implications to most non-smartphone users, I still advocate against making it part of the main core, where it doesn't belong, just for the reasons invoked. I sincerely doubt even Cisco would succeed in forcing a change in the IPv6 protocols to work around a bug in some of their routers. Please read me well: I really don't care which corner case behavior is the best in the future. I trust SQlite dev team to make the right choice(s) just like they have done already so many times. I also don't care as the library I'm maintaining (AutoIt UDF) works fine with both old and new versions and so do my own applications. What makes me answer to your poll is that the principle of changing a core component due to applicative bugs opens the route to endless negociations about which applicative bug should be worked around at SQLite level, which is completely backwards. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
