[whatwg] asynchronous JSON.parse
Robin Berjon
robin at w3.org
Fri Mar 8 01:44:50 PST 2013
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 if an async API for JSON existed, wouldn't the perf bottleneck
> then simply fall on whatever processing needs to be done afterwards?
But for that part you're in control of whether your processing is
blocking or not.
> 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 that snippet would be different from a single callback API.
There could possibly be value in an event-based API if you could set it
up with a filter, e.g. JSON.filtered("$.*").then(function (item) {});
which would call you for ever item in the root object. Getting an event
for every information item that the parser processes would likely flood
you in events.
Yet another option is a pull API. There's a lot of experience from the
XML planet in APIs with specific performance characteristics. They would
obviously be a lot simpler for JSON; I wonder how well that experience
translates.
--
Robin Berjon - http://berjon.com/ - @robinberjon
More information about the whatwg
mailing list