> You might have picked a bad demo project to show off the efficiency of NUM. It takes me 58 requests and (on my very fast connection) 5.3 seconds to download a

> You might have picked a bad demo project to show off the efficiency of NUM. It takes me 58 requests and (on my very fast connection) 5.3 seconds to download all the information for Barclays. That’s very slow, I’d be interested how much of the delay is from the DNS calls and how much is overhead from the demo site. We’ve purposely chosen to demo this site because it’s an example of an intensive NUM implementation. > Downloading a JSON blob with all the data for Barclays, parsing it, and displaying it, would take a fraction of the time. Of course, but that data doesn’t exist. Barclays’ phone numbers are split over hundreds of web pages which would require much more data download. I think your argument is that we could supply the data in JSON form, but then developers building on top of this data, would have to count out on our JSON response being fast and reliable. What we’re describing here is the current state-of-the-art, it’s an API model where developers usually pay to access that data. Barclays is a massive organisation with a very complicated contact setup. Smaller businesses are obviously much simpler, with all of their contact data contained within a single UDP packet of maybe 300 bytes.