>>>>>Don't know much about it either - but I think there are a couple of libraries which make for a more developer-friendly approach. This looks interesting:http://mozilla.github.io/localForage/#localforage.
>>>>>
>>>>>Seems it will use localStorage as a fall-back if IndexDB is not available....
>>>>
>>>>Since my target audience is iPad Mini (which means Safari) I quickly googled for IndexedDB and Safari on iOS and found claims that IndexedDB on iOS8 and 8.1 are buggy. This is bad.
>>>
>>>I read a blog which claims using the same id in too separate datastores then the record in one gets deleted ;-{
>>>
>>>> So I need to create a real case of customer data (which is not so easy) to see if localStorage is enough.
>>>
>>>Do they need *all* of the data from the server for off-line use or could they work with a subset ?
>>>
>>>> Another approach is to tell the customer that storing locally is not an option and store on the server. Actually I am pretty much convinced that I won't be able to deliver the program that will work in a completely disconnected fashion (that it, with no WiFi).
>>>
>>>If you can get passed the storage problem then I'd guess that the biggest problem, if multiple users are updating data off-line, would be synchronizing back to the server.......
>>
>>Have myself NOT thought through all the ramifications, but HTML5 supports file read access - you could "install" stable lookup data perhaps via file interface.
>
>Seems to me that the problem there is that it is *only* read-only - no way to store updated data.....

as always I was a bit short in explaining: If there is a worry of exceeding the limit available to localstorage, RO / lookup data does not have to be put there to guarantee offline functionality - only the W/RW data needs IndexDB or localstorage and there might fit more data if the RO data ir read via file "proxy" ;-)