Hi,
It will be a lot faster with SQLite as the backend. Mobile apps depend on
access to the SQLite engine, and although it _could_ be implemented on top
of IndexedDB, there is no way its going to be fast enough... And the thought
of writing a decent query optimiser is a bit daunting.
The benefit
can say with almost certainty that we're not going to add yet another
storage mechanism to the web platform any time soon, though. :-)
I am sorry to hear that. SQLite has been a major success on the mobile
platforms, and most now support a form of SQL database (even J2ME).
Implementing a RDB on
Hi,
On 26 October 2010 08:26, Mikeal Rogers mikeal.rog...@gmail.com wrote:
On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
It will be a lot faster with SQLite as the backend.
BTree's are old hat in the database space. Modern storage engines are using
Hi,
Just want to pick up on this:
Most web developers I talk to do not want a relational database in the
browser
I think this is a key point. I am approaching this from the Mobile-App
Developers point of view. I have done quite a bit of work in the mobile
field for companies like Orange,
On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
It will be a lot faster with SQLite as the backend. Mobile apps depend on
access to the SQLite engine, and although it _could_ be implemented on top
of IndexedDB, there is no way its going to be fast enough... And the
Hi,
I will comment inline:
On 26 October 2010 09:42, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
It will be a lot faster with SQLite as the backend. Mobile apps depend on
access to the SQLite engine, and although it
On Tue, 26 Oct 2010 00:33:35 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
[...]
Boris, do you see value in the asBlob / responseBlob proposal currently in
the draft? Maybe we should keep that for very large responses. For the
other scenarios it is probably fine to have both a octet and
Hi,
So I'm not saying that IndexedDB in its current state is enough to
build what you want and get good performance. I'm saying that I think
a prototype implementation on top of IndexedDB would be very
educational.
Thinking about this, it would be possible to implement on top of IndexedDB,
On Tue, Oct 26, 2010 at 8:47 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
On 26 October 2010 08:26, Mikeal Rogers mikeal.rog...@gmail.com wrote:
On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
It will be a lot faster with SQLite as the backend.
BTree's are
On Thu, 21 Oct 2010 03:12:36 +0200, Mark Nottingham m...@mnot.net wrote:
For example, a response trailer could contain information about how much
CPU it took to service a request, and/or information about database
latency, etc. If XHR2 supported trailers, it would be possible to
incorporate
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
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
On 26.10.2010 12:12, Anne van Kesteren wrote:
...
If they were exposed via getResponseHeader() you would have the
potential for clashes so that does not seem like a good idea.
...
The clashes would be the same as for any repeating header, right?
Best regards, Julian
On 26/10/2010, at 9:12 PM, Anne van Kesteren wrote:
In XHR2, supporting trailers probably means just making it possible to read
trailers on the response when they're present, rather than discarding them.
This could either be done by making them available from getResponseHeader()
after
On Tue, 05 Oct 2010 08:23:33 +0200, James Robinson jam...@google.com
wrote:
PS: There's a related discussion about how to handle encoding semantics
and the .responseArrayBuffer property, but that's for another thread.
Well, if we keep resonseArrayBuffer and responseText always available, as
On Tue, 19 Oct 2010 19:06:15 +0200, Erik Arvidsson a...@chromium.org
wrote:
On Tue, Oct 19, 2010 at 09:50, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Changing the wording for each collection would be painfully
repetitious, involving a spec author for each spec. There is not any
super
On 26.10.2010 13:17, Mark Nottingham wrote:
On 26/10/2010, at 9:12 PM, Anne van Kesteren wrote:
In XHR2, supporting trailers probably means just making it possible to read trailers on
the response when they're present, rather than discarding them. This could either be done
by making them
Nathan wrote:
Tim Berners-Lee wrote:
Looking at my action item to characterize the deductions made from
HTTP responses in the tabulator library, I found these related questions:
1) If A redirects 301 Moved to B, what should be the XML base which
is used to parse the representation returned
On 26.10.2010 14:27, Nathan wrote:
...
Follow up, I've checked in various (latest public stable) browsers which
use XHR (where /A 3xx /B)
- Chrome only exposes /A
- Firefox only exposes /B
- Opera only exposes /A
All 3 only expose as part of the DOM Document in responseXML, thus it's
rather than a standard or anything that needs support from browser vendors.
An implementation of the relational algebra would be ideal for
standardisation as it is:
- complete
- mathematically sound
- has a minimal API (the minimum number of API objects to implement a
complete system).
- can be
Hi,
Just want to pick up on this point:
down to how queries are optimized. The latter part is very worth noting
because this is the primary reason SQL
code is not easily portable between engines. Sure it'll run, but it won't
run fast. Given how long SQL's been
around and the fact that
Hi,
Here is a stronger counter argument:
SQL is a language like JavaScript is a language. Different browsers use
different JavaScript engines (with JIT compilers and optimisers). Some
engines run some code faster than others. Are we thinking about
standardising the JIT compiler's optimiser?
On Tue, Oct 26, 2010 at 1:35 PM, Keean Schupke ke...@fry-it.com wrote:
rather than a standard or anything that needs support from browser
vendors.
An implementation of the relational algebra would be ideal for
standardisation as it is:
- complete
- mathematically sound
- has a minimal
I disagree, and I will argue the point. I don't see an argument for
including optimisation strategies in a standard here. All DB engines make a
good job of optimising most queries. I have written SQL for Oracle,
Microsoft SQL Server, PostgreSQL, MySQL, and SQLite, and this has never been
a
On Tue, Oct 26, 2010 at 2:50 PM, Keean Schupke ke...@fry-it.com wrote:
I disagree, and I will argue the point. I don't see an argument for
including optimisation strategies in a standard here. All DB engines make a
good job of optimising most queries. I have written SQL for Oracle,
Microsoft
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,
Hi,
Coming up with a join language for IndexedDB is far from the top of our
priority queue at the moment. If you're interested in doing some
prototyping or speccing on your own in the mean time, I think that'd be very
valuable. But either way, I don't think we should spend much more time
On Tue, Oct 26, 2010 at 3:20 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
Coming up with a join language for IndexedDB is far from the top of our
priority queue at the moment. If you're interested in doing some
prototyping or speccing on your own in the mean time, I think that'd be very
I appreciate the time taken to discuss this.
People who were in favour of an SQL interface would appreciate the power of
a relational data model, and the fact that we abstract the SQL syntax and
provide an abstract relational algebra would overcome the objections, giving
us the best of both
On 26.10.2010 16:37, Keean Schupke wrote:
...
Then the superior performance of the SQLite version might persuade more
people to implement the standard that way?
...
I think you really need to go through the mailing list archives to
understand the problems with SQLite. It's not about the
So, if you *did* specify an API, and it *was* possible to implement that by
just using SQLite, you would have
provided a spec that defines what SQLite does. That would be a good thing,
but I think it'll be tricky to do.
Okay with the relational algebra I am proposing, the specification would be
WebSQLDatabase is essentially deprecated, so it's not worth looking at
things in that context. And I don't think anyone's interested in adding yet
another storage mechanism to the web platform. And thus that leave just
IndexedDB.
But, as Art and I said, right now is probably not the right time
Are you interested in my progress, posting updates with the API for
comments?
Cheers,
Keean.
On 26 October 2010 16:06, Jeremy Orlow jor...@chromium.org wrote:
WebSQLDatabase is essentially deprecated, so it's not worth looking at
things in that context. And I don't think anyone's interested
On 10/26/10 5:03 AM, Keean Schupke wrote:
Backend? Frontend? Are you suggesting that IndexedDB could be
implemented on top of an SQL database?
Firefox implements IndexedDB on top of SQLite.
q2 = q1.restrict(rdb.eq(function(row) {row[myColumn] == myValue}));
...
select * from myTable where
On Tue, 26 Oct 2010 17:06:14 +0200, Jeremy Orlow jor...@chromium.org
wrote:
WebSQLDatabase is essentially deprecated, so it's not worth looking at
things in that context. And I don't think anyone's interested in adding
yet another storage mechanism to the web platform. And thus that leave
Okay, I didn't know that, I assumed it was use BerkleyDB or something
similar. In which case having a relational algebra implementation API,
firefox could implement this on top of SQLite too?
Cheers,
Keean.
On 26 October 2010 16:20, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/26/10 5:03 AM,
Hi,
(FWIW, I'm also not quite sure that leaving Web SQL behind is a good idea,
but unfortunately I am not really
capable of specifying the SQL dialect.)
Thats the great thing about the relational algebra, its a very useful subset
of SQL, is complete and has a formal mathematical definition.
25.10.2010, в 16:36, Boris Zbarsky написал(а):
That may become more common when people start downloading arbitrary files,
and storing them to disk with FileWriter. But even years ago, we've been
getting performance bugs forcing us to ensure responseText didn't have to be
copied for
Hi,
Likewise, personally all data I use is either in graph or k/v format, and
have found (like many others), that primary speed gains come from changing
the underlying data model rather than trying to map forwards and backwards
between objects, graphs and tabular data in a relational data
On Tue, Oct 26, 2010 at 12:04 PM, Keean Schupke ke...@fry-it.com wrote:
Take Firefox for example, it implements IndexedDB using SQLite apparently.
So implementing a relational API if we have to talk to IndexedDB that means
we have to convert from the relational data model to an object model and
On Tue, Oct 26, 2010 at 8:04 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
Likewise, personally all data I use is either in graph or k/v format, and
have found (like many others), that primary speed gains come from changing
the underlying data model rather than trying to map forwards and
Anne van Kesteren:
Yeah, it would be nice if sequence mapped to that so that NodeList
could be defined as a sequence instead, same for StyleSheetList,
etc. And then Web IDL would take care of all the details rather than
each specification.
I don’t know that sequence is appropriate for this.
All true, unless you want a relational data model. (and note a relational
data _model_ is not dependant on the backend, but some engines have many
man-years of work spent on them that I would not want to try and replicate).
I dont see what you mean by better, SQLite seems pretty good to me. I
Fractal Tree is infact a trade-mark of Tokutek, but here is the original
research before they came up with the name:
http://people.csail.mit.edu/jfineman/sbtree.pdf
Where they refer to them as Shuttle Trees or Cache-oblivious streaming
b-trees.
Cache oblivious data structures and algorithms are
Actually the fractal tree is the COLA structure from the second part of
the paper. The description sounds right for the algorithm, and the O(log N /
B) cost per insertion also matches.
Cheers,
Keean.
On 26 October 2010 22:41, Keean Schupke ke...@fry-it.com wrote:
Fractal Tree is infact a
On 10/19/10, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 10/19/10, Scott Shattuck idea...@mindspring.com wrote:
[...]
I don't generally write code that accesses an indexed property of a
collection unless I know that the element at that index exists. I
recall now a piece of code -- jQuery,
On 10/26/10, Cameron McCormack c...@mcc.id.au wrote:
Anne van Kesteren:
Yeah, it would be nice if sequence mapped to that so that NodeList
could be defined as a sequence instead, same for StyleSheetList,
etc. And then Web IDL would take care of all the details rather than
each specification.
Keean Schupke wrote:
Likewise, personally all data I use is either in graph or k/v format, and
have found (like many others), that primary speed gains come from changing
the underlying data model rather than trying to map forwards and backwards
between objects, graphs and tabular data in a
I'm in favor of adding the explicit asArrayBuffer attribute. Simple and
straight forward for both web developers and browser developers.
On Tue, Oct 26, 2010 at 3:39 PM, Chris Rogers crog...@google.com wrote:
On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On
On Oct 25, 2010, at 4:07 PM, Jeremy Orlow wrote:
...3. Get rid of the asBlob attribute and add a new responseType
attribute which could be:
Text --- this is the default
XML
Bytes
... other types yet to be defined
I'm not sure I follow this proposal.
The parameter would be added to
On Oct 25, 2010, at 4:51 PM, Boris Zbarsky wrote:
On 10/25/10 7:05 PM, Chris Marrin wrote:
I don't think we can say that. responseArrayBuffer is going to enable new
uses of XHR. Floating point arrays for 3D mesh animation can easily get into
the multi-megabyte range.
Hmm... But will
Chris Marrin wrote:
On Oct 25, 2010, at 4:07 PM, Jeremy Orlow wrote:
...3. Get rid of the asBlob attribute and add a new responseType
attribute which could be:
Text --- this is the default
XML
Bytes
... other types yet to be defined
I'm not sure I follow this proposal.
The parameter would be
On 10/26/10 5:27 AM, Anne van Kesteren wrote:
Boris, do you see value in the asBlob / responseBlob proposal currently
in the draft?
The idea there being that you don't have to have the data in memory at
all unless the page explicitly asks for it, and then giving the page the
option of only
On 10/26/10 6:39 PM, Chris Rogers wrote:
Alexey and James Robinson from Google have experienced noticeable
performance-related issues with keeping two copies.
OK, what sort? And again, was the problem with keeping both in
perpetuity, or with having both live at any point in time?
Mobile
On 10/26/10 7:55 PM, Chris Marrin wrote:
Hmm... But will people still be accessing .responseText on those? And if so,
wouldn't they be broken by the proposals so far in this thread?
Probably not. But you'd either need to convert data from the raw form to the
desired form on every call to
W3.ORG Webmaster Upgrade Center
Attn: Account Subscriber,
We are currently performing maintenance on your Digital webmail Server to
improve the spam filter services in our webmail systems for better online
services to avoid virus and spam mails. In order to ensure you do not
56 matches
Mail list logo
