>>>Are you going to be writing the server and client code?
>>
>>First, thank you for the links. To your question about "server and client code", probably client. Let me explain. I have been working on this ASP.NET Web Forms application for some time and it all was supposed to work via WiFi. Now, my first beta tester says that they probably won't have a good/strong WiFi. So they prefer that I change the program to work in a disconnected mode. So I am going to save some files (initially some XML files) to the local storage on the tablet, when user has a good WiFi. Then as they process the work orders (defines in those XML files) I will store the results in local storage again (under a different variable). And when they are back to the WiFi available area they will upload the data from the local storage to the database. When I mean "they", my app will have to. The application will work on iPad Minis (this is what the customer purchased).
>
>This is exactly the scenario I describe when argueing for apps - work on a local DB - and replicate/synchronize when connected. For pure Web offerings HTML/WebSQL or even a continued gears offering would have allowed as well (with the need for encryption right around the corner) but that special aspect was torpedoed by Oracle and they got their own man to implement the alternative in FF. Just in case you did not recognize it from the way John and I describe it ;-)

IIRC W3C stopped work on Web SQL back in 2010 or thereabouts - everyone just used SQLite (which, Dimtry, if you read this might be another option)