In fairness, and perspective, GLSL is a big leap, adding one more language with
neat features like swizzle and matrix math.
SQL is too big a leap for the time being. I'd like to see a continued effort at
'borrowing' from our new web family member, glsl. Typed arrays are wonderful.
There's been
On Tue, Apr 5, 2011 at 9:33 PM, Joran Greef jo...@ronomon.com wrote:
On 06 Apr 2011, at 2:53 AM, Pablo Castro wrote:
The goal of IndexedDB has always been to enable things like RelationalDB and
CouchDB to be built on top, while maintaining a reasonable level of
functionality for those that
On 06 Apr 2011, at 8:56 AM, Jonas Sicking wrote:
1. Treat object values as opaque (necessary to avoid
deserialization/serialization overhead, this is mandatory for storing
anything over 50,000 objects on a device like an iPad or iPhone).
Please explain this in more detail as I have no
On Wed, Apr 6, 2011 at 3:21 AM, Joran Greef jo...@ronomon.com wrote:
On 06 Apr 2011, at 8:56 AM, Jonas Sicking wrote:
1. Treat object values as opaque (necessary to avoid
deserialization/serialization overhead, this is mandatory for storing
anything over 50,000 objects on a device like an
On 4/4/2011 8:07 AM, Joran Greef wrote:
SQLite has a fantastic track record of maintaining backwards compatibility.
Sort of. They didn't between SQLite 2 and SQLite 3. There also have
been some (albeit minor) backwards compatibility issues with SQLite 3.x
releases. The most serious of which
On 4/4/2011 10:28 AM, Joran Greef wrote:
Do you think it would be wise then to advocate doing away with SQLite before
IndexedDB has had a chance to prove itself? Surely two competing APIs would be
the fastest way to bring IndexedDB up to speed?
Who is advocating doing away with it? Note that
On 06 Apr 2011, at 6:26 PM, Shawn Wilsher wrote:
On 4/4/2011 8:07 AM, Joran Greef wrote:
SQLite has a fantastic track record of maintaining backwards compatibility.
Sort of. They didn't between SQLite 2 and SQLite 3. There also have been
some (albeit minor) backwards compatibility issues
On 4/4/2011 10:18 AM, Joran Greef wrote:
How would you create an index on an existing object store in IndexedDB
containing more than 50,000 objects on an iPad, without incurring any object
deserialization/serialization overhead, without being an order of magnitude
slower than SQLite, and
On 06 Apr 2011, at 6:49 PM, Shawn Wilsher wrote:
On 4/4/2011 10:18 AM, Joran Greef wrote:
How would you create an index on an existing object store in IndexedDB
containing more than 50,000 objects on an iPad, without incurring any object
deserialization/serialization overhead, without being
On 4/6/2011 9:44 AM, Joran Greef wrote:
We only need one fixed version of SQLite to be shipped across Chrome, Safari,
Opera, Firefox and IE. That in itself would represent a tremendous goal for
IndexedDB to target and to try and achieve. When it actually does, and
surpasses the fixed version
On 4/6/2011 10:06 AM, Joran Greef wrote:
I bring up the iPad example because I had experience with a LocalStorage
implementation (I think it was Safari) loading the contents of LocalStorage
into memory synchronously on first access, blocking the UI thread. I am
probably wrong on this one but
On Wed, Apr 6, 2011 at 10:14 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/6/2011 9:44 AM, Joran Greef wrote:
We only need one fixed version of SQLite to be shipped across Chrome,
Safari, Opera, Firefox and IE. That in itself would represent a tremendous
goal for IndexedDB to target and to
On 06 Apr 2011, at 7:14 PM, Shawn Wilsher wrote:
On 4/6/2011 9:44 AM, Joran Greef wrote:
We only need one fixed version of SQLite to be shipped across Chrome,
Safari, Opera, Firefox and IE. That in itself would represent a tremendous
goal for IndexedDB to target and to try and achieve. When
On 06 Apr 2011, at 7:24 PM, Tab Atkins Jr. wrote:
When a security bug is encountered, either the browsers update to a
new version of sqlite (if it's already been fixed), thus potentially
breaking sites, or they patch sqlite and then upgrade to the patched
version, thus potentially breaking
On 4/6/11 10:30 AM, Joran Greef wrote:
If Mozilla enjoys using the latest version of SQLite (and I assume they are not
planning on replacing internal SQLite embeddings with IndexedDB - not at this
stage at least), then web developers deserve the latest version.
This is not obvious a priori,
On 06 Apr 2011, at 7:42 PM, Boris Zbarsky wrote:
On 4/6/11 10:30 AM, Joran Greef wrote:
If Mozilla enjoys using the latest version of SQLite (and I assume they are
not planning on replacing internal SQLite embeddings with IndexedDB - not at
this stage at least), then web developers deserve
On Wed, Apr 6, 2011 at 10:42 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/6/11 10:30 AM, Joran Greef wrote:
If Mozilla enjoys using the latest version of SQLite (and I assume they
are not planning on replacing internal SQLite embeddings with IndexedDB -
not at this stage at least), then web
That's not the only reason. Mozilla laid out others ten months ago:
https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/
Mozilla's plan appears to be to implement IndexedDB on top of SQLite,
and then encourage developers to build SQL in javascript on top of
On 4/4/2011 10:15 AM, Ryan Fugger wrote:
That's not the only reason. Mozilla laid out others ten months ago:
https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/
Mozilla's plan appears to be to implement IndexedDB on top of SQLite,
and then encourage
On 4/4/11 10:15 AM, Ryan Fugger wrote:
That's not the only reason. Mozilla laid out others ten months ago:
https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/
Mozilla's plan appears to be to implement IndexedDB on top of SQLite,
This is not a plan so much
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Keean Schupke
Sent: Monday, April 04, 2011 10:17 PM
Something like RelationalDB gives you the power of a relational-db with no
dependence on a specific implementation of SQL, so it would be compatible
On 06 Apr 2011, at 2:53 AM, Pablo Castro wrote:
The goal of IndexedDB has always been to enable things like RelationalDB and
CouchDB to be built on top, while maintaining a reasonable level of
functionality for those that wanted to use it directly. I really like the
idea of thinking of
On 04 Apr 2011, at 4:39 PM, Jonas Sicking wrote:
Hence it would still be the case that we would be relying on the
SQLite developers to maintain a stable SQL interpretation...
SQLite has a fantastic track record of maintaining backwards compatibility.
IndexedDB has as yet no track record, no
This is ignoring the possibility that something like RelationalDB could be
used, where a well defined common subset of SQL can be used (and I use
well-defined in the formal sense). This would allow a relatively thin
wrapper on top of most SQL implementations and would allow SQLite (or BDB)
to be
On 04 Apr 2011, at 5:26 PM, Keean Schupke wrote:
This is ignoring the possibility that something like RelationalDB could be
used, where a well defined common subset of SQL can be used (and I use
well-defined in the formal sense). This would allow a relatively thin wrapper
on top of most
Yes, it already has well defined set operations. Solid is a matter of
testing by enough people (and if you wanted to try it and feed back that
would be a start). Fast should not be a problem, as the SQL database does
all the heavy lifting.
In more detail, Codd's six primitive operators are
On 4 April 2011 15:55, Keean Schupke ke...@fry-it.com wrote:
Yes, it already has well defined set operations. Solid is a matter of
testing by enough people (and if you wanted to try it and feed back that
would be a start). Fast should not be a problem, as the SQL database does
all the heavy
i've mostly stayed out of this thread because i felt like i'd just being fanning the flames but i really can't stay out anymore.
databases are more that SQL, always have been.
SQL is a DSL for relational database access. all implementations of SQL have a similar set of tools they implement first
On Mon, Apr 4, 2011 at 8:07 AM, Joran Greef jo...@ronomon.com wrote:
On 04 Apr 2011, at 4:39 PM, Jonas Sicking wrote:
Hence it would still be the case that we would be relying on the
SQLite developers to maintain a stable SQL interpretation...
SQLite has a fantastic track record of
Some thoughts:
On 4 April 2011 16:10, Mikeal Rogers mikeal.rog...@gmail.com wrote:
i've mostly stayed out of this thread because i felt like i'd just being
fanning the flames but i really can't stay out anymore.
databases are more that SQL, always have been.
SQL is a DSL for relational
On 4 April 2011 16:04, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 4, 2011 at 8:07 AM, Joran Greef jo...@ronomon.com wrote:
On 04 Apr 2011, at 4:39 PM, Jonas Sicking wrote:
Hence it would still be the case that we would be relying on the
SQLite developers to maintain a stable
I would point out that RelationalDB is relationally complete and the api
does not depend on the sqlite spec at all.
Cheers
Keean
On Apr 1, 2011 8:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Apr 1, 2011 at 12:39 PM, Glenn Maynard gl...@zewt.org wrote:
Lastly, some vendors have expressed
On 04 Apr 2011, at 6:10 PM, Mikeal Rogers wrote:
it's not very hard to write the abstraction you're talking about on top of
IndexedDB, and until you do it i'm going to have a hard time taking you
seriously because it's clearly doable.
You assume I have not written the abstraction I am
Joran Greef
April 4, 2011 April 4, 201110:18 AM
On 04 Apr 2011, at 6:10 PM, Mikeal Rogers wrote:
it's not very hard to
On 04 Apr 2011, at 6:04 PM, Tab Atkins Jr. wrote:
It's new.
Do you think it would be wise then to advocate doing away with SQLite before
IndexedDB has had a chance to prove itself? Surely two competing APIs would be
the fastest way to bring IndexedDB up to speed?
Ironically, the poor
On 4 April 2011 22:55, Aryeh Gregor simetrical+...@gmail.com wrote:
On Fri, Apr 1, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote:
There are several reasons why we don't want to rely exclusively on
SQLite, other than solely W3C formalia.
First of all, what should we do once the
I agree that it'd be best to have a spec independent of database platform,
which is why I was asking about an idea along the lines of RelationalDB
https://github.com/keean/RelationalDBor the example I gave in the email
which initiated this discussion, both of which are entirely abstracted from
the
On Sat, Apr 2, 2011 at 00:42:40, Glenn Maynard wrote:
You can certainly ask if they're interested in doing so, not for our
benefit (whoever our means), but for the benefit of the Web as a whole,
and there's nothing at all rude in asking. I'd say the opposite: it's rude
to assume they
I am incredibly uncomfortable with the idea of putting the
responsibility of the health of the web in the hands of one project.
In fact, one of the main reasons I started working at Mozilla was to
prevent this.
/ Jonas
I agree with you. All the more reason to support both WebSQL and
Pity.
Anyway RelationalDB defines its API without reference to the underlying SQL
or non-SQL database... So as a candidate for replacing WebSQL, it does not
suffer from that problem.
Cheers,
Keean.
On 2 April 2011 14:56, Glenn Maynard gl...@zewt.org wrote:
On Sat, Apr 2, 2011 at 5:24 AM,
On Thu, Mar 31, 2011 at 12:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
No, it actually sounds like a success; it prevented a specification being
created which would have been tied to a particular implementation, no matter
how widely-deployed.
For comparison, IE6 was very widely deployed
On 4/1/2011 5:40 AM, Nathan Kitchen wrote:
Are there any browser vendor representatives on the mailing list who would
care to comment on the criteria for implementing something akin to Keean's
RelationalDBhttps://github.com/keean/RelationalDB idea? What would need
to be in place to start work
On 4/1/2011 9:39 AM, Aryeh Gregor wrote:
IE6 is closed-source software written for a single platform. SQLite
is in the public domain, works for all major operating systems and
lots of minor ones, and is already used (I think?) by every major
browser except IE. That makes all the difference.
On Fri, Apr 1, 2011 at 9:39 AM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Thu, Mar 31, 2011 at 12:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
No, it actually sounds like a success; it prevented a specification being
created which would have been tied to a particular implementation, no
On Apr/1/2011 3:39 PM, ext Glenn Maynard wrote:
If SQLite was to be used as a web standard, I'd hope that it wouldn't
show up in a spec as simply do what SQLite does, but as a complete
spec of SQLite's behavior.
FYI, the Web SQL Database NOTE says:
[[
On Fri, Apr 1, 2011 at 12:39 PM, Glenn Maynard gl...@zewt.org wrote:
Lastly, some vendors have expressed unwillingness to embed SQLite for
legal reasons. Embedding other peoples code definitely exposes you to
risk of copyright and patent lawsuits. While I can't say that I fully
agree with this
On Fri, Apr 1, 2011 at 3:53 PM, Jonas Sicking jo...@sicking.cc wrote:
Creating such a spec would be a formidable task, of course.
Indeed. One that the SQL community has failed in doing so far. And
they have a lot more experience with SQL than we do.
That suggests a very different rationale
Hi Shawn
I would be interested in this. What would need to be done to make this a
Firefox plugin? I've done XPCOM stuff before in xulrunner if that's any
help.
Cheers,
Keean
On Apr 1, 2011 6:09 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/1/2011 5:40 AM, Nathan Kitchen wrote:
Are there
On Fri, 1 Apr 2011, Arthur Barstow wrote:
On Apr/1/2011 3:39 PM, ext Glenn Maynard wrote:
If SQLite was to be used as a web standard, I'd hope that it wouldn't show
up in a spec as simply do what SQLite does, but as a complete spec of
SQLite's behavior.
FYI, the Web SQL Database NOTE
On Fri, 1 Apr 2011, Glenn Maynard wrote:
On Fri, Apr 1, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote:
First of all, what should we do once the SQLite team releases a new
version which has some modifications in its SQL dialect? We generally
always need to embed the latest
On Sat, Apr 2, 2011 at 12:33 AM, Ian Hickson i...@hixie.ch wrote:
I don't find this compelling, because it assumes that the release
methodology of SQLite is fixed in stone.
It would be incredibly rude of us to force an independent team of
developers to change development practices for our
On Friday, April 1, 2011, Glenn Maynard gl...@zewt.org wrote:
On Sat, Apr 2, 2011 at 12:33 AM, Ian Hickson i...@hixie.ch wrote:
I don't find this compelling, because it assumes that the release
methodology of SQLite is fixed in stone.
It would be incredibly rude of us to force an
On 03/31/2011 05:19 PM, ext Nathan Kitchen wrote:
I've been watching discussions on IndexedDB for a while now, and
wondered if anyone would mind spending a few moments to explain how
IndexedDB is related (or not) to WebSQL. Is IndexedDB seen as replacing
the functionality originally offered by
That's nice, pretty much what I was thinking but somewhat more complete : )
Is there not a w3 group progressing something like this? And if not, who
would need to be lobbied to get one started?!
As an aside, I note you didn't implement date as a supported data type.
Was that a conscious decision,
On Thu, Mar 31, 2011 at 11:43 AM, Benjamin Poulain
benjamin.poul...@nokia.com wrote:
WebSQL in its current form is pretty dead, see
http://www.w3.org/TR/webdatabase/ :
quoteBeware. This specification is no longer in active maintenance and
the
Web Applications Working Group does not intend to
On 3/31/11 12:06 PM, Glenn Maynard wrote:
This is painful to read. WebSQL development died because SQLite, the
most widely-deployed database software in the world, was too good? That
sounds like a catastrophic failure of the W3C process.
No, it actually sounds like a success; it prevented a
No real reason - just trying to implement a minimal framework. Date objects
would be a definite must have going forward.
I was interested in trying to get something like this standardised, as I
believe it has none of the issues that stopped WebSQL, as it defines a
complete relational API
This is painful to read. WebSQL development died because SQLite, the most
widely-deployed database software in the world, was too good? That sounds
like a catastrophic failure of the W3C process.
--
Glenn Maynard
Hear.
I am starting to think that Mozilla will step up and provide an
On 31 March 2011 19:08, Joran Greef jo...@ronomon.com wrote:
This is painful to read. WebSQL development died because SQLite, the
most widely-deployed database software in the world, was too good? That
sounds like a catastrophic failure of the W3C process.
--
Glenn Maynard
Hear.
I
59 matches
Mail list logo
