There must be a break-even response size below which this is pointless, the server doesn't send responses byte by byte but in chunks the whole response could well be on the wire already so it would how zero impact on download footprint. The impact of TCP nagle makes this very hard to predict too so the chunk size will vary between server config and server workload at the time of the request.
Anyone that has developed an HTTP parser has experienced this. I feel like this is a problem to be solved in the server using JSON path or similar.
Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
71–74 of 74 posts
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#72Just merged in support for reading any stream in Node:
https://github.com/jimhigson/oboe.js#reading-from-any-stream...
oboe( fs.createReadStream( '/home/me/secretPlans.json' ) )
.node('!.schemes.*', function(scheme){
console.log('Aha! ' + scheme);
});
.node('!.plottings.*', function(deviousPlot){
console.log('Hmmm! ' + deviousPlot);
})
.done(function(){
console.log("*twiddles mustache*");
});Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#73Earlier quoted context omitted.
in my experience, you need to set flush to SYNC for it to work on chrome without manually flushing
Do you know how to do that from node? Here's the little test service I wrote to stream out some gzipped content: https://github.com/jimhigson/oboe.js/blob/master/test/stream...
You need to construct the stream with flush: require('zlib').Z_SYNC_FLUSH
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#74Is it intentional that it accepts invalid JSON? I ask only because most of the examples on that page would not be valid as the name part of the key:value pairs needs to be quoted. PS: Don't upvote this, it's a minor detail and the big point about the use-case is far more important than this comment.
Parsing is built on top of Clarinet (see where the name comes from?) https://github.com/dscape/clarinet Unquoted JSON in docs is a mistake. I'll take a look now.
One could be forgiven for thinking it comes from SAX, which is probably where Clarinet comes from.