I'd like to propose as a constructive strategy not to flame/offend
everybody right off the bat. I'm sure there's reasons, I'd like to hear
them, too.
On Fri, Nov 9, 2012 at 7:24 PM, Todd Blanchard toddvblanch...@gmail.comwrote:
It has been two years since the following little note was attached
My recollection is that some vendors refused to ever support SQLite, making
a SQL-based standard not really feasible. You can undoubtedly review the
w3c archives to find out more details if you want to know the rationale
they expressed at the time.
It's unfortunate that IndexedDB is still not
Don't care if it is SQLite so long as it is a real relational database.
IndexedDB or some other key-value store is no substitute for the power of a
relational database and is unlikely to be performant given the number of
different views we support. I don't mind too much if IE used mssql,
Todd - your e-mail fails the respectful manner requirement of the
group's e-mail policy (#Mail-List-Etiqutte).
Please restrict the content of your e-mails to respectful technical
comments.
If you continue to fail to abide with this policy, your posting rights
to this list will be removed.
On Mon, 12 Nov 2012 10:14:47 +0100, Andrew Wilson atwil...@google.com wrote:My recollection is that some vendors refused to ever support SQLite, making a SQL-based standard not really feasible. You can undoubtedly review the w3c archives to find out more details if you want to know the rationale
On Mon, Nov 12, 2012 at 1:12 PM, Charles McCathie Nevile
cha...@yandex-team.ru wrote:
The Webapps group will continue to try and reach industry agreement on
ways to handle data storage for offline applications. Help is appreciated.
Trying to help is generally appreciated too.
A slight
On Nov 12, 2012, at 4:30 AM, Florian Bösch wrote:
On Mon, Nov 12, 2012 at 1:12 PM, Charles McCathie Nevile
cha...@yandex-team.ru wrote:
The Webapps group will continue to try and reach industry agreement on ways
to handle data storage for offline applications. Help is appreciated. Trying
On Mon, Nov 12, 2012 at 1:36 PM, Todd Blanchard toddvblanch...@gmail.comwrote:
Wondering what is wrong with the blob type in SQLite?
A couple of things
1) Array buffers can't be passed to websql
2) websql is subject to the hard quota (5mb) and I'm talking about
gigabytes of data
3)
On Mon, Nov 12, 2012 at 4:30 AM, Florian Bösch pya...@gmail.com wrote:
On Mon, Nov 12, 2012 at 1:12 PM, Charles McCathie Nevile
cha...@yandex-team.ru wrote:
The Webapps group will continue to try and reach industry agreement on
ways to handle data storage for offline applications. Help is
On Mon, Nov 12, 2012 at 3:49 PM, Kyle Huey m...@kylehuey.com wrote:
Er, IndexedDB should handle ArrayBuffers just fine. If you're seeing
problems with that that's an implementation bug, not a case that the spec
failed to handle.
You're right it does, I just checked. Nevertheless there are
Your best bet is to report implementation/performance issues to the browser
vendors, rather than here, unless you believe that there is something
inherent in the spec that results in slow implementations.
I'd say in the specific case of Chrome, we probably have not optimized for
the case of
On Mon, Nov 12, 2012 at 9:52 AM, Joshua Bell jsb...@google.com wrote:
Per the spec, anything the structured cloning algorithm [1] handles can be
used as record values in IndexedDB. ArrayBuffers are not on that list, but
Chrome does support them in IndexedDB.
The TypedArray spec specifies how
For anyone that's confused, I sent from the wrong email address so non-list
recipients received my reply but the list did not.
And Kyle's right, as I realized when following up before re-sending.
On Mon, Nov 12, 2012 at 9:56 AM, Kyle Huey m...@kylehuey.com wrote:
On Mon, Nov 12, 2012 at 9:52
On Nov 12, 2012, at 4:43 AM, Florian Bösch wrote:
On Mon, Nov 12, 2012 at 1:36 PM, Todd Blanchard toddvblanch...@gmail.com
wrote:
Wondering what is wrong with the blob type in SQLite?
A couple of things
1) Array buffers can't be passed to websql
Could be fixed.
2) websql is subject to
On Mon, Nov 12, 2012 at 7:19 PM, Todd Blanchard toddvblanch...@gmail.comwrote:
Gigabytes of data? Why would one subject WebSQL to a hard quote of 5M and
think using gigabytes of user disk space in a different scenario is OK?
Something seems out of balance here. Why limit one but not the
On Mon, 12 Nov 2012 19:27:33 +0100, Florian Bösch pya...@gmail.com wrote:
The hard quota is not my idea. It's what those browsers who do implement
WebSQL implement. Unlike IndexedDB which triggers a do you want to allow
yadda yadda or whatever, at least sometimes, WebSQL is hard limited to
On Mon, Nov 12, 2012 at 7:42 PM, João Eiras jo...@opera.com wrote:
You're again confusing implementation details with the specification. User
agents are free to implement whatever quota management they want, as long
as it's transparent and respects the visible effects on the webpage side.
On Nov 12, 2012, at 10:27 AM, Florian Bösch wrote:
The hard quota is not my idea. It's what those browsers who do implement
WebSQL implement. Unlike IndexedDB which triggers a do you want to allow
yadda yadda or whatever, at least sometimes, WebSQL is hard limited to 5mb.
Actually, asking
On Mon, 12 Nov 2012 19:50:20 +0100, Florian Bösch pya...@gmail.com wrote:
On Mon, Nov 12, 2012 at 7:42 PM, João Eiras jo...@opera.com wrote:
You're again confusing implementation details with the specification.
User
agents are free to implement whatever quota management they want, as
long
Similarly the vendors deciding not wanting to support WebSQL isn't a spec
issue and it should be filed in the bug tracker of your favorite vendor.
On Mon, Nov 12, 2012 at 8:02 PM, João Eiras jo...@opera.com wrote:
On Mon, 12 Nov 2012 19:50:20 +0100, Florian Bösch pya...@gmail.com
wrote:
On
On 11/12/12 8:17 AM, Florian Bösch wrote:
This testsite: http://codeflow.org/issues/indexeddb.html
Putting 50mb takes between 2.5 to 8 seconds. Getting it between 2 to 4
seconds.
Putting 100mb doesn't work in Chrome at all and throws an exception on
the put after half a second.
After fixing
Care to paste that one? I'll test it in firefox.
On Mon, Nov 12, 2012 at 9:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/12/12 8:17 AM, Florian Bösch wrote:
This testsite:
http://codeflow.org/issues/**indexeddb.htmlhttp://codeflow.org/issues/indexeddb.html
Putting 50mb takes between
On 11/12/12 12:31 PM, Florian Bösch wrote:
Care to paste that one? I'll test it in firefox.
http://pastebin.mozilla.org/1937689
-Boris
In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about 500ms.
On Mon, Nov 12, 2012 at 10:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/12/12 12:31 PM, Florian Bösch wrote:
Care to paste that one? I'll test it in firefox.
On 11/12/12 1:56 PM, Florian Bösch wrote:
In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about 500ms.
For what it's worth, I did some measuring, and the main performance cost
centers for the write (the CPU-intensive ones, not the disk access) seem
to be:
1) Making a copy
A-ha. Filled payload with random. Now it's FF 4.4s put, 5.5s get. In line
with chromes perf.
On Mon, Nov 12, 2012 at 11:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/12/12 1:56 PM, Florian Bösch wrote:
In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about
500ms.
For
On 11/12/12 2:59 PM, Florian Bösch wrote:
A-ha. Filled payload with random. Now it's FF 4.4s put, 5.5s get. In
line with chromes perf.
Hmm. This I can't reproduce. I tried filling the array with randoms,
and the times end up about 30% higher, but not 20x higher, for me.
-Boris
It has been two years since the following little note was attached to the Web
SQL Spec
This document was on the W3C Recommendation track but specification work has
stopped. The specification reached an impasse: all interested implementors have
used the same SQL backend (Sqlite), but we need
28 matches
Mail list logo
