I think that may be part of the author's point. The api isn't solving the underlying problem it's solving the api problem and they're different. Quite often a

I think that may be part of the author's point. The api isn't solving the underlying problem it's solving the api problem and they're different. Quite often a lot of the implementation complexity is exposed even though there's no real need as far as the api is concerned. Largely because no-one really designed the api, it followed on from the implementation. Not that I'm defending the implementation but I do have one quibble with the article. The author didn't need real time events but he used an rt api. Under those circumstances it's pretty hard to come up with a protocol that doesn't expose some of the complexity without incurring a penalty on either the system or the api. Having said that, the usual approach is to restrict what you can do so it can't cause damage in which case you can usual make a simple api.