Hi Keeane, Jeremy, All,
Thanks for starting this thread Keean.
I agree with Jeremy that a API on top of IndexedDB, WebSQLDB, etc. would
be interesting (e.g. performance data).
It's also not clear to me (ATM) that such an API should necessarily be
put on WebApps' "standards" track. As always, the "devil's in the
details". I think we also need to be careful about not including too
many features in the first version of our specs.
-Art Barstow
On Oct/26/2010 6:45 AM, ext Jeremy Orlow wrote:
Great! This is exactly the type of thing we were hoping to see happen
on top of IndexedDB. :-)
For the record, I don't think the performance comparisons will be
super useful until browser vendors have time to work on basic
performance optimizations of their engines and until some effort is
put into query optimization in the library (or at least giving authors
a way to give hints on how to optimize it), but as time goes on,
such comparisons should be quite useful.
As for the standards/support side of your question: such a library
would actually be much more like a library (like JQuery) rather than a
standard or anything that needs support from browser vendors.
Standards will come into play if we pull bits of your API into the
standards, much like how CSS selectors were quite popular in libraries
and eventually got pulled into the web platform itself.
When we are ready to add joins and such to the API, we'll definitely
be looking at what implementations out there are popular. And even
before that, any code using IndexedDB will be very helpful for testing
and optimizing browsers' IndexedDB backends.
J
On Tue, Oct 26, 2010 at 11:16 AM, Keean Schupke <ke...@fry-it.com
<mailto:ke...@fry-it.com>> wrote:
Hi,
I am beginning to think that a basic implementation on top of
IndexedDB may be workable (no query optimiser). The advantage
would be that once the API becomes standardised, browser
implementers may choose to have an alternate backend using SQLite
or another RDBMS.
So what I would like to propose producing a JavaScript API for the
relational algebra. The API will be split into a frontend (query
tree construction) which is visible to the user, and a backend
that is invisible (either executing the query using IndexedDB, or
WebSQL). This would be interesting for several reasons, it would
allow direct performance comparisons between IndexedDB and an
RDBMS for relational queries, it would provide a framework for
implementing a query optimiser for IndexedDB, and would allow
testing the IndexedDB relational operators against a known
database engine. It would also provide two implementations for
standardising.
The aim would be to standardise the API, allowing any
implementation of the backend.
Would this be something that I could get support for?
Cheers,
Keean.
