3 ms·

> 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 deprecat

> 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.

tpmoney 2y ago
> The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden, So you agree then that a public API would likely necessitate a slower pace of change. It’s good to finally get on the same page. > If you're using it as an example of how a public API can't evolve then it's a lousy example. I agree, so it’s a good thing I have never once claimed that a public API can’t evolve, or that would have been a terrible example of that. In fact that argument would be completely ridiculous in the face of a number of APIs that have absolutely evolved in public. What my argument is and always has been since the beginning is that a public API imposed costs on that evolution and almost certainly implies a slower pace of change. And TLS absolutely backs that up. If you want to use TLS1.3 everywhere, you can’t. If you don’t want any sites to use TLS1.1 anymore, you can’t make that happen either. And the folks that make TLS can’t do anything about that either.
- rstuart4133 2y ago
  > So you agree then that a public API would likely necessitate a slower pace of change. It’s good to finally get on the same page. Not at all. The pace of change is determined by how fast you introduce new API's. Apple in particular can change API's the iPhone talks to their watches as fast as they want, because they control both ends. Them publishing the protocol has absolutely no effect on that. > What my argument is and always has been since the beginning is that a public API imposed costs on that evolution and almost certainly implies a slower pace of change. Despite everything you've said here, I still don't know what those costs are beyond maintaining deprecated API's and documenting the API. > If you want to use TLS1.3 everywhere, you can’t. You're not Apple. Trust me, if Apple decided their watches and phones should only connect using TLS 1.3, then that's what would happen on the next release. You apparently are claiming being forced to publish they are now using TLS 1.3 would slow them down, but haven't offered a shred of evidence or a coherent reason on why that would be so. On looking back, you haven't said anything new in this reply - you just repeated the same assertions. Sadly I have said anything new either, which means it's time to move on.

tpmoney 2y ago

> The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden, So you agree then that a public API would likely necessitate a slower pace of change. It’s good to finally get on the same page. > If you're using it as an example of how a public API can't evolve then it's a lousy example. I agree, so it’s a good thing I have never once claimed that a public API can’t evolve, or that would have been a terrible example of that. In fact that argument would be completely ridiculous in the face of a number of APIs that have absolutely evolved in public. What my argument is and always has been since the beginning is that a public API imposed costs on that evolution and almost certainly implies a slower pace of change. And TLS absolutely backs that up. If you want to use TLS1.3 everywhere, you can’t. If you don’t want any sites to use TLS1.1 anymore, you can’t make that happen either. And the folks that make TLS can’t do anything about that either.

rstuart4133 2y ago
> So you agree then that a public API would likely necessitate a slower pace of change. It’s good to finally get on the same page. Not at all. The pace of change is determined by how fast you introduce new API's. Apple in particular can change API's the iPhone talks to their watches as fast as they want, because they control both ends. Them publishing the protocol has absolutely no effect on that. > What my argument is and always has been since the beginning is that a public API imposed costs on that evolution and almost certainly implies a slower pace of change. Despite everything you've said here, I still don't know what those costs are beyond maintaining deprecated API's and documenting the API. > If you want to use TLS1.3 everywhere, you can’t. You're not Apple. Trust me, if Apple decided their watches and phones should only connect using TLS 1.3, then that's what would happen on the next release. You apparently are claiming being forced to publish they are now using TLS 1.3 would slow them down, but haven't offered a shred of evidence or a coherent reason on why that would be so. On looking back, you haven't said anything new in this reply - you just repeated the same assertions. Sadly I have said anything new either, which means it's time to move on.