On 07/03/2013 23:34 , Tobie Langel wrote:
In which case, isn't part of the solution to paginate your data, and
parse those pages separately?
Assuming you can modify the backend. Also, data doesn't necessarily have
to get all that bulky before you notice on a somewhat sluggish device.
Even
On Friday, March 8, 2013 at 10:44 AM, Robin Berjon wrote:
On 07/03/2013 23:34 , Tobie Langel wrote:
Wouldn't some form of event-based API be more indicated? E.g.:
var parser = JSON.parser();
parser.parse(src);
parser.onparse = function(e) { doSomething(e.data); };
I'm not sure how
On Thu, Mar 7, 2013 at 7:29 PM, Adam Barth w...@adambarth.com wrote:
I don't have strong feelings one way or another. Generally, I think
it's a good idea if the presence of the Origin header isn't synonymous
with the request being a CORS request because that could limit our
ability to use the
Le 08/03/2013 02:01, Glenn Maynard a écrit :
If you're dealing with lots of data, you should be loading or creating
the data in the worker in the first place, not creating it in the UI
thread and then shuffling it off to a worker.
Exactly. That would be the proper way to handle a big amount of
Let me answer your question about the scenario, before entering the
specifics of an API.
For the moment, the main use case I see is for asynchronous
serialization of JSON is that of snapshoting the world without stopping
it, for backup purposes, e.g.:
a. saving the state of the current region in
Le 07/03/2013 23:18, David Rajchenbach-Teller a écrit :
(Note: New on this list, please be gentle if I'm debating an
inappropriate issue in an inappropriate place.)
Actually, communicating large JSON objects between threads may cause
performance issues. I do not have the means to measure
On 3/8/13 2:01 AM, Glenn Maynard wrote:
(Not nitpicking, since I really wasn't sure what you meant at first, but
I think you mean a JavaScript object. There's no such thing as a JSON
object.)
I meant a pure data structure, i.e. JavaScript object without methods.
It was my understanding that
I fully agree that any asynchronous JSON [de]serialization should be
stream-based, not string-based.
Now, if the main heavy duty work is dealing with the large object, this
can certainly be kept on a worker thread. I suspect, however, that this
is not always feasible.
Consider, for instance, a
Hi,
Has anyone had a chance to look at my proposals to improve the HTML
specification with regard to navigating browsing contexts while sandboxed?
Thanks,
Bob
Message: 3
Date: Sat, 9 Feb 2013 16:26:12 +
From: Bob Owen bobowenc...@gmail.com
To: wha...@whatwg.org
Subject: [whatwg] HTML
Le 08/03/2013 13:34, David Rajchenbach-Teller a écrit :
I fully agree that any asynchronous JSON [de]serialization should be
stream-based, not string-based.
Now, if the main heavy duty work is dealing with the large object, this
can certainly be kept on a worker thread. I suspect, however, that
On 3/8/13 1:59 PM, David Bruant wrote:
Consider, for instance, a browser implemented as a web application,
FirefoxOS-style. The data that needs to be collected to save its current
state is held in the DOM. For performance and consistency, it is not
practical to keep the DOM synchronized at all
On Fri, Mar 8, 2013 at 4:51 AM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
a. saving the state of the current region in an open world RPG;
b. saving the state of an ongoing physics simulation;
These should live in a worker in the first place.
c. saving the state of the browser
Le 08/03/2013 15:29, David Rajchenbach-Teller a écrit :
On 3/8/13 1:59 PM, David Bruant wrote:
Consider, for instance, a browser implemented as a web application,
FirefoxOS-style. The data that needs to be collected to save its current
state is held in the DOM. For performance and consistency,
On Fri, 8 Mar 2013, Bob Owen wrote:
Has anyone had a chance to look at my proposals to improve the HTML
specification with regard to navigating browsing contexts while
sandboxed?
Both your e-mail and your bug are on my list of feedback to process. Right
now, I'm working on bugs primarily.
On Fri, Mar 8, 2013 at 2:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Mar 7, 2013 at 7:29 PM, Adam Barth w...@adambarth.com wrote:
I don't have strong feelings one way or another. Generally, I think
it's a good idea if the presence of the Origin header isn't synonymous
with the
On Fri, Mar 8, 2013 at 6:21 PM, Adam Barth w...@adambarth.com wrote:
I would recommend including an Origin header in every non-GET request
(and, of course, in some GET requests because of CORS).
That sounds fairly straightforward. Thanks!
--
http://annevankesteren.nl/
On 3/8/13 5:35 PM, David Bruant wrote:
Intuitively, this sounds like:
1. collect data to a JSON;
I don't understand this sentence. Do you mean collect data in an object?
My bad. I sometimes write JSON for object that may be stringified to
JSON format and parsed back without loss, i.e. a bag of
On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
There's an unfortunate mismatch currently. new
XMLHttpRequest({anon:true}) will generate a request where a) origin is
a globally unique identifier b) referrer source is the URL
about:blank, and c) credentials are
On Sat, Feb 23, 2013 at 6:48 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Feb 23, 2013 at 4:59 AM, Stephen White
senorbla...@chromium.orgwrote:
On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan
On Thu, Mar 7, 2013 at 4:18 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
I have put together a small test here - warning, this may kill your
browser:
http://yoric.github.com/Bugzilla-832664/
By the way, I'd recommend keeping sample benchmarks as minimal and concise
as
20 matches
Mail list logo
