Possible redesign (new version)

[brodycj]

This plugin does its job reasonably well but is complex to maintain. It would be nice to break it down into smaller components that would be easier to maintain, possibly by different people in the future. In case of such a "redesign" it should be able to almost completely pass the existing test suite.

One idea could be to start with the JavaScript part from https://github.com/nolanlawson/cordova-plugin-sqlite-2 (ref: #547) and move the native parts into one or more separate projects.

Another idea would be to turn this around: start with a mostly-native sqlite3 storage part with an API similar to https://github.com/mapbox/node-sqlite3 and then move the Web SQL API part to a pure-JS shim (or just use something like https://github.com/nolanlawson/node-websql). The one drawback with this idea is that it would need https://github.com/kripken/sql.js/ to work in the browser platform.

A major goal in case of a redesign would be to keep the native parts as blocks that could be reassembled more easily to provide special versions such as SQLCipher without the need to keep merging new fixes.

[brodycj]

From #547 (comment):

I like your idea for merging both projects! What's your rough estimate how long a merge might take?

It would probably take me several weeks to make a decent working prototype. I do not expect to have any time before December 2016.

[brodycj]

Major redesign will definitely not be part of the upcoming major release (#687), still keeping open for future consideration. An additional goal of the redesign will be support for other frameworks such as React Native and possibly Nativescript.

[brodycj]

Additional item could be to support user defined functions (#741) - not expected to be practical on Cordova for reasons described that issue.

[brodycj]

Also adding that as discussed in #576 (comment) and #576 (comment) SQL.js would likely be suitable for the browser platform.

[brodycj]

The ultimate solution may be to divide the SQLite functionality as follows:

• existing SQLite implementation without OS implementation [1] and possibly without pager functionality compiled to asm.js or Web Assembly
• pluggable file-based persistence part

Benefits would include:

• much nicer API would be possible across browser and major mobile platforms
• should be able to provide flexible and consistent functionality across Cordova and web applications
• easier to benefit from SQLite updates
• much easier to plug and play features such as Spatialite [2], CSV [3], SQLCipher implementation
• public domain terms would be possible

Pluggable persistence part could work with Cordova File API plugin, W3 File API, possibly even IndexedDB, etc.

This means no more Cordova sqlite plugin needed, a nice step towards the "ultimate purpose of PhoneGap" [4]:

The ultimate purpose of PhoneGap is to cease to exist.

[1] https://sqlite.org/arch.html
[2] storesafe/cordova-sqlite-storage-help#32
[3] storesafe/cordova-sqlcipher-adapter#54
[4] https://phonegap.com/blog/2012/05/09/phonegap-beliefs-goals-and-philosophy/

P.S. This idea would also solve the problems with named parameters (#717) and user defined functions (#741)

[brodycj]

Closing this issue in favor of the discussion in #862.