On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky wrote:
> On 10/25/10 6:21 PM, Chris Rogers wrote:
>
>> People are concerned that it would require keeping two copies of the
>> data around (raw bytes, and unicode text version) since it's unknown
>> up-front whether "responseText", or "responseArray
On Tue, Oct 26, 2010 at 5:43 PM, Boris Zbarsky wrote:
> 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 e
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
experien
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 re
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 d
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 ma
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 paramete
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
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
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 wrote:
>
>
> On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky wrote:
>
>> On 10/25/10 6:21 PM, Chris Rogers wrote
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 relati
On 10/26/10, Cameron McCormack 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.
>
> I
On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky wrote:
> On 10/25/10 6:21 PM, Chris Rogers wrote:
>
>> People are concerned that it would require keeping two copies of the
>> data around (raw bytes, and unicode text version) since it's unknown
>> up-front whether "responseText", or "responseArray
On 10/19/10, Garrett Smith wrote:
> On 10/19/10, Scott Shattuck 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, in fact-- wherein an "optimized"
> `for`
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 wrote:
> Fractal Tree is infact a trade-mark of Tok
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 ar
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 don'
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
On Tue, Oct 26, 2010 at 8:04 PM, Keean Schupke 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 backwards
On Tue, Oct 26, 2010 at 12:04 PM, Keean Schupke 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
> then back t
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
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
Jonas Sicking wrote:
On Mon, Oct 25, 2010 at 10:24 AM, Keean Schupke wrote:
We (www.fry-it.com) produce websites and mobile apps. We have been looking
at HTML5 for developing mobile apps, and for the kind of apps that we want
to produce the client side WebSQL API provided what we needed. The In
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.
In
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 wrote:
> On 10/26/10 5:03 AM, Keean Schupke wr
On Tue, Oct 26, 2010 at 4:24 PM, Anne van Kesteren wrote:
> On Tue, 26 Oct 2010 17:06:14 +0200, Jeremy Orlow
> 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 mec
On Tue, 26 Oct 2010 17:06:14 +0200, Jeremy Orlow
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
just
IndexedDB.
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
Are you interested in my progress, posting updates with the API for
comments?
Cheers,
Keean.
On 26 October 2010 16:06, Jeremy Orlow 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
> a
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 t
>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 b
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 *quali
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 worlds
On Tue, Oct 26, 2010 at 3:20 PM, Keean Schupke 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
>> valuab
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 tim
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,
On Tue, Oct 26, 2010 at 2:50 PM, Keean Schupke 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 SQL
>
>
>> 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
On Tue, Oct 26, 2010 at 1:35 PM, Keean Schupke 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 API (the
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?
Che
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 diffe
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
impo
>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
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 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 ava
On Tue, 19 Oct 2010 19:06:15 +0200, Erik Arvidsson
wrote:
On Tue, Oct 19, 2010 at 09:50, Garrett Smith
wrote:
Changing the wording for each collection would be painfully
repetitious, involving a spec author for each spec. There is not any
super interface collection defined that also defines
On Tue, 05 Oct 2010 08:23:33 +0200, James Robinson
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
suggested in the
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()
>>
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
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 i
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 prop
On Thu, 21 Oct 2010 03:12:36 +0200, Mark Nottingham 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 this informat
On Tue, Oct 26, 2010 at 8:47 AM, Keean Schupke wrote:
> Hi,
>
> On 26 October 2010 08:26, Mikeal Rogers wrote:
>
>> On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke wrote:
>>
>>> Hi,
>>>
>>> It will be a lot faster with SQLite as the backend.
>>>
>>
>> BTree's are old hat in the database space.
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, 26 Oct 2010 00:33:35 +0200, Boris Zbarsky 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 string
representat
Hi,
I will comment inline:
On 26 October 2010 09:42, Jonas Sicking wrote:
> On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke 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
>
On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke 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 thought
> of
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, Vodaf
Hi,
On 26 October 2010 08:26, Mikeal Rogers wrote:
> On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke 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
>> Fractal-Trees for a 50-80 times sp
On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke 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
> Fractal-Trees for a 50-80 times speedup in write performance. The browser
> should not be trying to
> 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,
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
62 matches
Mail list logo
