W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

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

From: Drew Wilson <atwilson@google.com>
Date: Tue, 19 May 2009 18:00:39 -0700
Message-ID: <f965ae410905191800v5aebba56ic06a2e3f5b111420@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC