31–40 of 74 posts
edit: Also how is this faster, if you're parsing an incomplete response over and over again isn't each parse blocking, wouldn't this approach kill your FPS?
This is basically node-trumpet in the browser. Really great stuff! https://github.com/substack/node-trumpet
Hadn't seen that before. Interesting link, thanks. Very similar except JSON/JSONPath instead of HTML/CSS. Oboe runs fine in Node but I want to make the code a bit more standards-y. Ie, using Node's EventEmitters instead of the little pubsub I made for the browser.
Btw what are you using for the Node side, JSONStream?
This probably won't work if you have gzip on, right?
I'll have to test to be sure you still get streaming. It depends how the browsers handle xhr2 events with regard to gzip'd http. I /think/ it'll be fine but I need to check to be sure. Eg, with gzip on you still get progressive html rendering.
';
flush();
ob_flush();
sleep(20);
echo 'Bye';
?>
Besides, even if you manage to stream it, I imagine inflating partially received content is not trivial for the browser.
The main difference between multipart XHR and Oboe, that I can see, is that MHXR requires you to format your data in a specific manner (using a magic delimiting character), though I'm curious if the base method is similar or not.
I was wondering when some of these types of libs might make their way into the world, I know I saw in Nicholas Zakas' book "High Performance JavaScript"[1] that he demonstrated how to read back (process) a large AJAX result in chunks, allowing you to begin working with the response before it was finished downloading. It was called "multipart XHR", and he shows a neat code example and then links to a site that has sam…
1 Create XHR, listen to XHR2 progress event. 2 Use Clarinet.js SAX parser, scoop up all events. 3 From SAX events, build up actual JSON and maintain path from root to actual node. 4 Match that path (+ some other stuff) against registered JSONPath specs. 5 Fire callbacks if they pass.
This seems like it could be used to create a protocol similar to XMPP - which I always enjoyed from the perspective of elegance. I might have a pet project this weekend, thanks for sharing.
No worries. This is my masters dissertation btw.
You could serialise a state history as it happens, allowing your users to modify the futere state in real time and push to the always unfolding history stream. Could be great for games.
I built this for more-or-less standard downloading, only quicker. But, yeah, if you set a server up to feed it you could use it for lots of creative things.
Earlier quoted context omitted.
Its probably not worth changing it if it is eg in a file already, but if the process to generate it is a slow one it might be.
I agree. If you're doing something slow/asynchronous like aggregating several http resources it is worth it to write out as early as you can but keep server-side the same if you can generate the whole JSON quickly.
Earlier quoted context omitted.
Its probably not worth changing it if it is eg in a file already, but if the process to generate it is a slow one it might be.
I agree. If you're doing something slow/asynchronous like aggregating several http resources it is worth it to write out as early as you can but keep server-side the same if you can generate the whole JSON quickly.
On the server side, you may run into an error after you started writing out your reply. That may cause an incomplete reply. It may require more involved error handling between the server and client. 'Gather first write later' approach gives you a simpler error propagation between server and client.