- From: Drew Wilson <atwilson@google.com>
- Date: Tue, 19 May 2009 18:00:39 -0700
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. 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). -atw On Tue, May 19, 2009 at 5:26 PM, Brett Zamir <brettz9 at yahoo.com> wrote: > I would like to suggest an incremental though I believe significant > enhancement to Offline applications/SQLite. > > 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. > > 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. > > 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. > > (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.) > > Brett > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090519/f3f2500b/attachment.htm>
Received on Tuesday, 19 May 2009 18:00:39 UTC