joombar

26 ms·

1.
by joombar 12y ago
I realise not the usual format for a story. But to Gawk... in this world of zero downtime deploys this is remarkable. As the sun rises in the UK, this is half the business shut down during business hours.
2.
9 hour deploy and counting. Major UK retail site – still down as stores open.(argos.co.uk)
3 points by joombar 12y ago|1 comments
3.
by joombar 13y ago
"And they're right- a boy who enjoys t-shirts and sports is at a tremendous social advantage over one prefers dresses and ballet" Perhaps in some very conservative societies. Where I live I'm confident that a boy who ent
4.
by joombar 13y ago
For small messages it will be slightly slower in terms of CPU time because of JS vs native DOM parser. But for small messages the time taken with modern JS engines should be less than a monitor refresh. For small messages on fast networks t
5.
Show HN: Visualising how streaming AJAX speeds up the web(oboejs.com)
13 points by joombar 13y ago|2 comments
6.
by joombar 13y ago
Two different user agent strings for one version of one browser? That can change at any moment based on a list the site authors don't control? There's no way that'd ever confuse things!
7.
by joombar 13y ago
Just 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(&#
8.
by joombar 13y ago
Well, you could have a JSON which was valid at the start and invalid at the end. It'd parse the first bit ok and only throw an error when it got to the invalid bit. Nothing gets parsed more than once. SAX parsers already parse streams,
9.
by joombar 13y ago
No, although that's a nice idea and something I'd like to look into.
10.
by joombar 13y ago
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...
11.
by joombar 13y ago
In meantime, made a bug report: https://code.google.com/p/chromium/issues/detail?id=309092
12.
by joombar 13y ago
Quick experiment says: Gzip can be written out as a stream ok. Can't comment on Apache but Node does it fine. Firefox's xhr fires progress events for gzipped content but not Chrome's. Looking to see if I can find a way round
13.
by joombar 13y ago
It should make most calls faster. Exceptions are for small JSON files or on networks that are fast enough there is no streaming effect (the whole file arrives very quickly) For most sites there'll be some users where it will make it fa
14.
by joombar 13y ago
it is built on top of a sax parser.
15.
by joombar 13y ago
Liable to change but "An approach to i/o for rest clients which is neither batch nor stream; nor SAX nor DOM." I'm writing it now.
16.
by joombar 13y ago
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.
17.
by joombar 13y ago
There's only a node side so far as I needed to write for some component tests. It'd work with anything that writes out valid JSON. The client side works in Node right now as well as in the browser but it is a bit browser-y. It is
18.
by joombar 13y ago
If you don't care about old browsers you could use the same connection to keep the state updated as you used to download the original state. I built this for more-or-less standard downloading, only quicker. But, yeah, if you set a serv
19.
by joombar 13y ago
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 act
20.
by joombar 13y ago
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
21.
by joombar 13y ago
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.
22.
by joombar 13y ago
Hmmmm, yeah. Use cases doesn't take up much space, I'll put that before examples because it explains better what it is for.
23.
by joombar 13y ago
There's a cool thing you might try where you can download the historic messages, then continue to stream live ones over the same http. If you don't care about old browsers (anything without xhr2 progress events) should work fine t
24.
by joombar 13y ago
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
25.
by joombar 13y ago
Should be fixed now. Thanks for pointing out. There's a test explicitly for not allowing this: https://github.com/jimhigson/oboe.js/blob/master/test/specs/...
26.
by joombar 13y ago
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.
27.
by joombar 13y ago
I suppose the example is a little artificial. It isn't really for using some of the JSON response while ignoring the rest (well, you can use it for that but it isn't the main use). I got the idea for this project working on data v
28.
by joombar 13y ago
No worries. This is my masters dissertation btw.
29.
by joombar 13y ago
It will work with any JSON but It'll work faster if you write the JSON out a bit at a time. Consider if you are writing data from a db: you can either collect all the rows together then write them out, or you can write them out one at
30.
by joombar 13y ago
No changes required. It should accept any JSON resource. Having said that, there's a much bigger improvement if you're progressively writing out the JSON rather than doing it in one big lump.

More ›