One alternate approach to providing this support would be via shared, cross-domain workers (yes, workers are my hammer and now everything looks like a nail :) - this seems like one of the canonical uses of cross-domain workers, in fact.<br>
<br>This would be potentially even more secure than a simple shared database, as it would allow the application to programmatically control access from other domains, synchronize updates, etc while allowing better controls over access (read-only, write via specific exposed write APIs, etc).<br>
<br>-atw<br><br><div class="gmail_quote">On Tue, May 19, 2009 at 5:26 PM, Brett Zamir <span dir="ltr"><<a href="mailto:brettz9@yahoo.com">brettz9@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I would like to suggest an incremental though I believe significant enhancement to Offline applications/SQLite.<br>
<br>
That is, the ability to share a complete database among offline applications according to the URL from which it was made available. It could be designated by the origin site as a read-only database, or also potentially with shared write access, shareable with specific domains or all domains, and perhaps also with a mechanism to indicate the license of its contents.  Perhaps the manifest file could include such information. Actually, there might even be a shared space for databases directly downloaded by the user (or by an application) which would allow all applications access, no doubt requiring UA permission.<br>

<br>
Ideally the origin site could also have control over providing an update to the database (not necessarily through manually performing UPDATE commands, but potentially by simply providing a new database at the previous location which was checked periodically for a new modification date). I don't know whether it would ideal to tie this in to the caching API (perhaps deleting the database reference could also cause it to be re-downloaded and also force the database to be re-created). Perhaps the cache API could also be optionally shared with other domains as well, allowing them to ensure their application was working with the latest data.<br>

<br>
I believe custom protocols will also play into this well, as there could be a number of uses for operating on the same data set while linking to it in a way which is application-independent.<br>
<br>
(Thanks to Kristof Zelechovski for helping me distill the essence of the idea a bit more succinctly and more in line with HTML 5's progress to date.)<br><font color="#888888">
<br>
Brett<br>
</font></blockquote></div><br>