问存储脱机web应用程序的图像数据(客户端存储数据库)

EN

- CON: any change of a PNG database item will mean complete download of all items in manifest (Really bad news!)

- CON: Designed for JSON storage
- CON: can only store blobs via base64 encoding (probably fatal flaw due to cost of de-encoding)
- CON: Hard limit of 5MB for webStorage [http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html](http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html)

- CON: Sponsor will reject it as a native app requiring certification

- Server creates a zip file, places it in wwwroot, and notifies client
- user has to manually unzip (At least that is how I see it) and save to client file system
- Web app uses FileSystem API to reference files
- CON: ZIP might be too large (zip64?), long time to create
- CON: Not sure if FileSystem API can always read out of the sandbox (I think so)

- The user will be local to the server before going offline
- So we could have him insert a SD card, let the server fill it with PNG files
- Then the user will plug it into the laptop, tablet
- Web app will use FileSystem API to read the files
- CON: Not sure if FileSystem API can always read out of the sandbox (I think so)

- CON: w3c has abandoned it (pretty bad)
- I might consider a Javascript wrapper that uses IndexedDB and WebSQL as a fall-back

- Chrome supports read/write of blobs
- CON: not clear about IE and FireFox (IE10, has non-standard msSave)
- caniuse.com reports IOS and Android support (but again, is this just r/w of JSON, or does it include the full blob API for writing?
- CON: FireFox folks dislike FileSystem API & not clear if they are supporting saving blobs: [https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/](https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/)
- PRO: _Much_ faster than IndexedDB for blobs according to jsperf [http://jsperf.com/indexeddb-vs-localstorage/15](http://jsperf.com/indexeddb-vs-localstorage/15) (page 2)

- Good support in IE10, FireFox (save, read blobs)
- Good speed and easier management than a file system (deletes, updates)
- PRO: see speed tests: [http://jsperf.com/indexeddb-vs-localstorage/15](http://jsperf.com/indexeddb-vs-localstorage/15)
- See this article on storing and display of images in IndexedDB: [https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/](https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/)
- CON: I confirmed that Chrome does not yet support blob writing (current bug, but not clear when it will be fixed)
- UPDATE: [A June 2014 blogpost](https://developers.google.com/web/updates/2014/07/Blob-support-for-IndexedDB-landed-on-Chrome-Dev) suggests Chrome now supports blobs in `IndexedDB`
- UPDATE: [This caniuse/indexeddb](https://caniuse.com/#search=indexeddb) confirms: "Chrome 36 and below did not support Blob objects as indexedDB values."; suggesting >Chrome36 supports Blob objects.

- PRO: very clean wrapper for IndexedDB, WebSQL or whatever database you have (think polyfill)
- CON: cannot store binary blobs, only data:uri (base64 encoding) (probably fatal flaw due to cost of de-encoding)

- Parashuram has writtent a nice JQUERY wrapper for the raw IndexedDB interface
- PRO: greatly simplifies using IndexedDB, I was hoping to add a shim/polyfill for Chrome FileSystemAPI
- CON: It should handle blobs, but I was unable to get it to work

- Eric Bidelman @ Google has written a well tested PolyFill the FileSystem API that uses Indexed DB as a fall back
- PRO: FileSystem API is well suited for storing blobs
- PRO: works great on FireFox and Chrome 
    - PRO: great for synchronizing with cloud based CouchDB

- CON: no clear why, but it is not working on IE10

- great for syncing a CouchDB with a local DB (uses either WebSQL or IndexedDB (not my problem though)
- CON: NO CONS, PouchDB now supports binary blobs for all recent browsers (IE, Chrome, Firefox, Chrome on mobile, etc.) as well as many older browsers. That was not the case when I first did this post.