Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
There appears to be some debate about ‘the divide is between wanting an SDK and wanting to know the underlying protocol’ (see http://www.tbray.org/ongoing/When/199x/1999/08/18/BitsOnTheWire).
I don’t really understand what this is referring to, or why they are mutually exclusive.
What is the philosophy of each approach and why do they conflict?
They’re not really mutually exclusive. It’s more of a continuum, but the development philosophy behind systems tends to gravitate towards one end or the other.
Essentially bits on the wire says the communication protocol is simple enough that it can be described to outside developers via some relatively simple (or even informal) specification. This means the service can be used in all kinds of unforeseen ways, and the service consumer need not be an official supported platform.
On the other hand, companies with monolithic offerings like Apple and Microsoft have the luxury of choosing another philosophy, which is to build a complete end-to-end SDK. In theory this makes life easier for developers by abstracting away the complexities of the underlying protocols, simultaneously freeing up the product to do more complex things, and reducing developer error. Of course there are still bits, and they still go over the wire, and they can be reverse engineered. However this will be considerably (orders of magnitude) more difficult to do than to use a protocol that was designed to be understandable, especially if it was intentionally obfuscated or encrypted to serve business interests.