4 ms·

> Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. > ... > Once it's out there you can't change the API without

> Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. > ... > Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. Or as I put it in the original comment: "Open protocols are great but they are also absolutely a hinderance on change" > Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that. They can, all they have to do is push out an update for those watches. That's the point. Because that API is private an exclusively used by Apple and Apple's software, they can replace it as many times as they want provided they are willing to push the updates. On the other hand, if hundreds of third parties are using that API independently, even if they push an update they still have to contend with a whole ecosystem of products that will or won't update on whatever schedule those developers feel like operating on. Apple already catches a bunch of flak for the speed at which they update and abandon their current public APIs, hardly an incentive to also open up their private APIs. > Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6. I'm not sure I'd call the transition to IPv6 an example of a resounding success of fast iteration on a change to a protocol or API. It's only been 30 years and we're still using IPv4 for most things and slapping band-aid upon band-aid on the problems, never mind the list of headache switching to exclusive IPv6 (for example, unless something has changed recently, you still can't use DHCPv6 to manage IPs for android devices)

rstuart4133 2y ago
> Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. And my point was I don't agree. It's not that it's public. It's that it's in use. > They can, all they have to do is push out an update for those watches. An update they can't be sure every watch has done. The usual solution is to that situation is to plan for it from day 1, design the watches so the very first ones you release can detect that's happened, and when it has issue an error message like "sorry, you'll have to update your watch to continue". Compare to: you design an API, as part of the design it queries what version the servers support, and issues a message like "your new end point doesn't support me any more, you need to upgrade something". Sounds very similar, doesn't it? Example: ssh will stop running if your old client connects to a new server. It's a public API. Example: SSL/TLS has moved through multiple incompatible versions. It's a very public API. So apparently the API being public didn't stop transitioning to new, incompatible versions when the need arose. What will stop it is not designing your API with upgrades in mind. If you don't do that, you will end up in a world of pain regardless of whether the API is public or not. You say it slows things down, but that's not necessarily correct either. Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem.
- tpmoney 2y ago
  > It's not that it's public. It's that it's in use. And an API that isn't public can have its use restricted to a controlled set of environments and places, which inherently makes it easier to update. > Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem. Until the EU decides that a public API that changes without warning and "arbitrarily" to suit Apple's needs is also anti-competitive. An argument that would easily be made the first time Apple shipped an update to the API that broke a bunch of third party devices even while their own devices continued to work fine because they received an update at the same time, or even early in preparation. Again, my argument is not that it is impossible to make a public API or to transition that API. My argument is that a public API by its very nature often implies a slower pace of change. Even in your examples, SSL and TLS upgrades often happen over many years, with deprecated older versions being supported along side the current version for a while. In fact, TLS is a great example of this, where TLS 1.1 had fixed the vulnerabilities that made the BEAST attacks possible, and yet in 2011, when BEAST was discovered, it was still a problem because in 5 years, TLS1.1 still hadn't had a lot of adoption. Or consider that TLS 1.3 has been out since 2018, and yet I can still connect to this very site using TLS 1.1 with weak encryption keys. In fact, if I change firefox to require TLS 1.3, I can't even connect to this site. Or consider further that initial TLS 1.3 rollout was hampered by middle layers that had implemented the spec badly (https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/ https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...). Again these are not insurmountable problems, but they are problems inherent with a public API or protocol that multiple vendors are implementing, and problems that Apple either does not have to deal with, or deals with on a much smaller scale with their private internal APIs and therefore can move faster when iterating on those APIs.
  - rstuart4133 2y ago
    > Until the EU decides that a public API that changes without warning The usual solution is not to break the existing API, but to add new features and deprecate old ones. I doubt the EU will demand Apple not improve their API's. The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden, but it can't be that bad as Linux, Windows and Android have maintained old API's for literally decades, so I'm sure Apple would cope. Or to put it another way, the fact that Apple has to support a depreciated API for a while doesn't mean they are forced to use it. If they want to make a change, they publish their shiny new API and move to it immediately. The existence of the old one doesn't need to slow Apple down at all. > In fact, TLS is a great example of this If you're using it as an example of how a public API can't evolve then it's a lousy example. TLS did evolve, and fairly rapidly. The fact that some people elected to stay with the old version doesn't change that. Frankly for most people BEAST didn't matter, as what they were doing on the internet didn't need a lot of security. But when it did matter, like say for a bank, then you were forced to upgrade. And guess what - that new browser still worked with old sites that support the new version. So some people chose to not move didn't slow the protocol's evolution at all. I think you are confusing the rate of adoption of something new, and the rate new things can arise and change. They are at best vaguely related. And to state the obvious, the old SSL API's being public had no effect on speed of the introduction a new version, which is the opposite of what you seem to be claiming.

rstuart4133 2y ago

> Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. And my point was I don't agree. It's not that it's public. It's that it's in use. > They can, all they have to do is push out an update for those watches. An update they can't be sure every watch has done. The usual solution is to that situation is to plan for it from day 1, design the watches so the very first ones you release can detect that's happened, and when it has issue an error message like "sorry, you'll have to update your watch to continue". Compare to: you design an API, as part of the design it queries what version the servers support, and issues a message like "your new end point doesn't support me any more, you need to upgrade something". Sounds very similar, doesn't it? Example: ssh will stop running if your old client connects to a new server. It's a public API. Example: SSL/TLS has moved through multiple incompatible versions. It's a very public API. So apparently the API being public didn't stop transitioning to new, incompatible versions when the need arose. What will stop it is not designing your API with upgrades in mind. If you don't do that, you will end up in a world of pain regardless of whether the API is public or not. You say it slows things down, but that's not necessarily correct either. Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem.

tpmoney 2y ago
> It's not that it's public. It's that it's in use. And an API that isn't public can have its use restricted to a controlled set of environments and places, which inherently makes it easier to update. > Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem. Until the EU decides that a public API that changes without warning and "arbitrarily" to suit Apple's needs is also anti-competitive. An argument that would easily be made the first time Apple shipped an update to the API that broke a bunch of third party devices even while their own devices continued to work fine because they received an update at the same time, or even early in preparation. Again, my argument is not that it is impossible to make a public API or to transition that API. My argument is that a public API by its very nature often implies a slower pace of change. Even in your examples, SSL and TLS upgrades often happen over many years, with deprecated older versions being supported along side the current version for a while. In fact, TLS is a great example of this, where TLS 1.1 had fixed the vulnerabilities that made the BEAST attacks possible, and yet in 2011, when BEAST was discovered, it was still a problem because in 5 years, TLS1.1 still hadn't had a lot of adoption. Or consider that TLS 1.3 has been out since 2018, and yet I can still connect to this very site using TLS 1.1 with weak encryption keys. In fact, if I change firefox to require TLS 1.3, I can't even connect to this site. Or consider further that initial TLS 1.3 rollout was hampered by middle layers that had implemented the spec badly (https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/ https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...). Again these are not insurmountable problems, but they are problems inherent with a public API or protocol that multiple vendors are implementing, and problems that Apple either does not have to deal with, or deals with on a much smaller scale with their private internal APIs and therefore can move faster when iterating on those APIs.
- rstuart4133 2y ago
  > Until the EU decides that a public API that changes without warning The usual solution is not to break the existing API, but to add new features and deprecate old ones. I doubt the EU will demand Apple not improve their API's. The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden, but it can't be that bad as Linux, Windows and Android have maintained old API's for literally decades, so I'm sure Apple would cope. Or to put it another way, the fact that Apple has to support a depreciated API for a while doesn't mean they are forced to use it. If they want to make a change, they publish their shiny new API and move to it immediately. The existence of the old one doesn't need to slow Apple down at all. > In fact, TLS is a great example of this If you're using it as an example of how a public API can't evolve then it's a lousy example. TLS did evolve, and fairly rapidly. The fact that some people elected to stay with the old version doesn't change that. Frankly for most people BEAST didn't matter, as what they were doing on the internet didn't need a lot of security. But when it did matter, like say for a bank, then you were forced to upgrade. And guess what - that new browser still worked with old sites that support the new version. So some people chose to not move didn't slow the protocol's evolution at all. I think you are confusing the rate of adoption of something new, and the rate new things can arise and change. They are at best vaguely related. And to state the obvious, the old SSL API's being public had no effect on speed of the introduction a new version, which is the opposite of what you seem to be claiming.