Nothing is stopping anyone from contributing code to make the driver more complete. Just grab the source and start hacking. If you see a function that's not supported - just add it.
The key problem I see, however, is one of wider adoption. Someone who is new to SQLite/JDBC, and looking to evaluate SQLite by doing a test port of their application to it, would see the lack of full API support as one more impediment along the way, perhaps one that they might not be technically capable of handling. (There are lots of people like that, who are skilled at integrating and configuring Java components into their system, but don't have coding skills.) Worse yet, if they don't have available the source code for their system, there is just no way they can do the port, because they can't change the code. Net effect, they give up on SQLite, which I think is a pity. IMHO, the fewer there are of such impediments to porting, the greater is the possibility of wide acceptance of SQLite.
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLiteJDBC" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups-beta.google.com/group/sqlitejdbc?hl=en -~----------~----~----~----~------~----~------~--~---
