[whatwg] Cross-domain databases; was: "File package protocol and manifest support?"

[Rob Kroeger]

Hi,

On Tuesday, May 19, 2009, Drew Wilson <atwilson at google.com> wrote:
> 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.

For what it's worth, this was my immediate thought as well upon
reading the idea. The database is insufficiently fast on some
platforms to server as an IPC mechanism and there are practical
limitations with having too many contending transactions so my
instinct would be to build large integrated web apps with a shared
worker routing data between components.

Rob.

>
> 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
>
>

-- 
Rob Kroeger
rjkroege at liqui.org
http://www.liqui.org