Re:Oboe.js: reacting to Ajax/Rest quicker by not waiting for...
by joombar on Friday October 18, 2013 @11:15AM
(#6571820)
I haven't looked at MXHR but here's roughly what Oboe does:
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.
Re:Oboe.js: reacting to Ajax/Rest quicker by not waiting for...
by k3n on Friday October 18, 2013 @11:35AM
(#6571932)
Interesting. After looking at the MXHR more, it appears as though it was adapted from Digg.com[1] (aka DUI.Stream[2]), and then later adapted by Facebook[3].
Yours sounds more elegant in that it can handle JSON naturally, but I wonder if the other might be better suited for binary content (not sure in which context that would make sense, if any).
Either way, I find them all fascinating, and I've starred your project :) Will keep an eye on it.
1. http://techfoolery.com/mxhr/mxhr.js
Re:Oboe.js: reacting to Ajax/Rest quicker by not waiting for...
by joombar on Friday October 18, 2013 @12:45PM
(#6572348)
I suppose you could make a binary equivalent if you needed to. You'd need to make some kind of binary matching language, maybe like Erlang's binary matching.
Adding XML/XPATH support would be a natural extension.
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.
1. http://shop.oreilly.com/product/9780596802806.do
2. http://techfoolery.com/mxhr/