right now JSON.parse blocks the mainloop, this gets more and more of an
issue as JSON documents get bigger and are also used as serialization
format to communicate with web workers.
To handle large JSON Documents there is a need for an async JSON.parse,
something like:
JSON.parse(data,
(It's hard to talk to somebody called j, by the way. :)
On Thu, Mar 7, 2013 at 2:06 AM, j...@mailb.org wrote:
right now JSON.parse blocks the mainloop, this gets more and more of an
issue as JSON documents get bigger
Just load the data you want to parse inside a worker, and perform the
The JSON object and its API are part of the ECMAScript language
specification which is standardized by Ecma/TC39, not whatwg.
Rick
On Thursday, March 7, 2013, wrote:
right now JSON.parse blocks the mainloop, this gets more and more of an
issue as JSON documents get bigger and are also used
On Thu, Mar 7, 2013 at 9:29 AM, Rick Waldron waldron.r...@gmail.com wrote:
The JSON object and its API are part of the ECMAScript language
specification which is standardized by Ecma/TC39, not whatwg.
He's talking about an async interface to it, not the core parser. It's a
higher level of
On Thu, Mar 7, 2013 at 10:42 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 7, 2013 at 9:29 AM, Rick Waldron waldron.r...@gmail.comwrote:
The JSON object and its API are part of the ECMAScript language
specification which is standardized by Ecma/TC39, not whatwg.
He's talking about an
On Wed, Mar 6, 2013 at 3:21 PM, Anne van Kesteren ann...@annevk.nl wrote:
Unless PHP does not expose Origin under HTTP_ORIGIN in $_SERVER as one
would expect...
(It does btw.)
So I also tested the fetch from an origin in the specification
http://dump.testsuite.org/fetch/form.html and it turns
On Thu, Mar 7, 2013 at 9:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Mar 6, 2013 at 3:21 PM, Anne van Kesteren ann...@annevk.nl wrote:
Unless PHP does not expose Origin under HTTP_ORIGIN in $_SERVER as one
would expect...
(It does btw.)
So I also tested the fetch from an origin
(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 reception speed
simply (which would be used to implement
I'd like to hear about the use cases a bit more.
Generally, structured data gets bulky because it contains more items, not
because items get bigger.
In which case, isn't part of the solution to paginate your data, and parse
those pages separately?
Even if an async API for JSON existed,
On Thu, Mar 7, 2013 at 2:18 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
(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
It is.
However, to use Transferable objects for purpose of implementing
asynchronous parse/stringify, one needs conversions of JSON objects
from/to Transferable objects. As it turns out, these conversions are
just variants on JSON parse/stringify, so we have not simplified the issue.
Note that I
On Thu, Mar 7, 2013 at 4:18 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
(Note: New on this list, please be gentle if I'm debating an
inappropriate issue in an inappropriate place.)
(To my understanding of this list, it's completely acceptable to discuss
this here.)
Actually,
12 matches
Mail list logo
