- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 10 Jun 2009 06:50:44 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 9 June 2009 23:50:44 UTC