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

[Ian Hickson]

On Wed, 20 May 2009, Brett Zamir 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.
> [...]

On Tue, 19 May 2009, Drew Wilson 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.
> 
> 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 

On Wed, 20 May 2009, Rob Kroeger wrote:
> 
> 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.

On Thu, 28 May 2009, Michael Nordman wrote:
> 
> I buy this thinking too as a better strategy for integrating web apps.

Based on the above comments, I haven't added the requested feature at this 
time -- let's see if the existing features can be used to do it first.


On Thu, 28 May 2009, Michael Nordman wrote:
> 
> But still, the ability to download a fully formed SQL database, and then 
> run SQL against it would be nice.
> 
> openDatabaseFromURL(urlToDatabaseFile);
> 
> * downloads the database file if needed (per http cache control headers)
> * the database can reside in an appcache (in which case it would be
> subject to appcache'ing rules instead)
> * returns a read-only database object
> 
> Of course, there is the issue of the SQL database format.

On Thu, 28 May 2009, Anne van Kesteren wrote:
> 
> Would there be a lot of overhead in just doing this through XMLHttpRequest,
> some processing, and the database API?

On Thu, 28 May 2009, Michael Nordman wrote:

> Good question. I think you're suggesting...
> * statementsToCreateAndPopulateSQLDatabase  = httpGet();
> * foreach(statement in above) { execute(statement); }
> * now you get to run queries of interest
> 
> Certainly going to use more client-side CPU than downloading a fully 
> formed db file. I think the download size would greater (all of the 
> 'INSERT into' text overhead), but thats just a guess. A database 
> containing FTS tables would change things a bit too (even less 
> client-side cpu, but more download size).

On Fri, 29 May 2009, Anne van Kesteren wrote:
> 
> There are certainly drawbacks, but given that we still haven't nailed 
> all the details of the database API proposal discussed by the WebApps WG 
> (e.g. the SQL syntax) and given that it has not been deployed widely, it 
> seems somewhat premature to start introducing convenient APIs around it 
> that introduce a significant amount of complexity themselves. Defining 
> the rules for parsing and creating a raw database file in a secure way 
> is a whole new layer of issues and the gain seems small.

On Fri, 29 May 2009, Michael Nordman wrote:
> 
> I don't think this feature's time has come yet either. Just food for 
> thought.

I guess we'll wait on this for now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'