4 ms·

> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns

> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns-resolver https://github.com/apple/swift-async-dns-resolver

josephcsible 2y ago
It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- virtue3 2y ago
  no no, it's just "ours is better", "think different", and "it just works". /s
  - masklinn 2y ago
    It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
- tpmoney 2y ago
  As near as I can tell, Apple doesn't call it a legacy API. The article does, but the article wasn't written by nor does it appear to be quoting Apple.
- threeseed 2y ago
  You actually think that a Swift developer, developing against Cocoa APIs, targeting Mac and iOS devices cares about a portable API. Because not sure if you know this but the entire software industry is built on high level libraries on top of largely portable code. For example this Swift library wraps c-ares a portable API.
- kccqzy 2y ago
  Well but the portable API is too low-level and error prone. What is the last time you used getaddrinfo? How often do you actually need to use it? One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.
  - o11c 2y ago
    getaddrinfo isn't its predecessors, there's nothing error-prone about it. The only thing that's nontrivial is falling back if the first server is unresponsive, and even there the obvious calling code is fine for almost all apps.
    - kccqzy 2y ago
      If you are using getaddrinfo directly, you likely wouldn't bother to implement Happy Eyeballs, for example.
      - o11c 2y ago
        And for almost all programs, that doesn't matter in $CURRENTYEAR.
- mzs 2y ago
  That's what you use to create a utility like nslookup in swift, Apple does not want you to do any resolving yourself, just pass a hostname instead: https://developer.apple.com/documentation/network/nwendpoint/host/init(_:)?language=swift https://developer.apple.com/documentation/network/nwendpoint...
  - ruthmarx 2y ago
    > Apple does not want you to do any resolving yourself Which honestly sounds like a good reason to make sure you do do it yourself.
    - EraYaN 2y ago
      Not at all actually, passing hostnames means they can fully handle happy eyeballs for you and all other performance optimizations that you can do if you resolve and connect in one call.
      - ruthmarx 2y ago
        It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.
        EraYaN 2y ago
        But you are already on their OS, so they would always be able to do that. They make the kernel, the hardware and it's firmware, so it's a moot point and needless paranoia. Might as well use the API that gives a better user experience.
        ruthmarx 2y ago
        > so it's a moot point and needless paranoia. No it's not. You are misunderstanding my point. I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely. I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPhone with the justification being safety or 'for the children' or whatever. That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.
- matheusmoreira 2y ago
  It's not necessarily EEE. Maybe it's just that the old wheel sucks. They want a better wheel and so they reinvented it, hopefully better this time. The corporations making proprietary software are not the only ones who have that attitude. I've resolved to make all my free software Linux-exclusive so that I can use Linux to the fullest. The Linux kernel is packed full of exclusive non-portable features that very few people take advantage of because they're obsessed with portability, POSIX compliance or whatever. I think that's a waste. Portable software is usually sucky lowest common denominator software. We should not limit ourselves to whatever glibc offers.
- ryandrake 2y ago
  It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.
  - pram 2y ago
    OpenGL is legacy in general, its been on 4.6 for almost a decade.
  - pjmlp 2y ago
    It is also legacy from Khronos point of view.

josephcsible 2y ago

It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
virtue3 2y ago
no no, it's just "ours is better", "think different", and "it just works". /s
- masklinn 2y ago
  It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
tpmoney 2y ago
As near as I can tell, Apple doesn't call it a legacy API. The article does, but the article wasn't written by nor does it appear to be quoting Apple.
threeseed 2y ago
You actually think that a Swift developer, developing against Cocoa APIs, targeting Mac and iOS devices cares about a portable API. Because not sure if you know this but the entire software industry is built on high level libraries on top of largely portable code. For example this Swift library wraps c-ares a portable API.
kccqzy 2y ago
Well but the portable API is too low-level and error prone. What is the last time you used getaddrinfo? How often do you actually need to use it? One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.
- o11c 2y ago
  getaddrinfo isn't its predecessors, there's nothing error-prone about it. The only thing that's nontrivial is falling back if the first server is unresponsive, and even there the obvious calling code is fine for almost all apps.
  - kccqzy 2y ago
    If you are using getaddrinfo directly, you likely wouldn't bother to implement Happy Eyeballs, for example.
    - o11c 2y ago
      And for almost all programs, that doesn't matter in $CURRENTYEAR.
mzs 2y ago
That's what you use to create a utility like nslookup in swift, Apple does not want you to do any resolving yourself, just pass a hostname instead: https://developer.apple.com/documentation/network/nwendpoint/host/init(_:)?language=swift https://developer.apple.com/documentation/network/nwendpoint...
- ruthmarx 2y ago
  > Apple does not want you to do any resolving yourself Which honestly sounds like a good reason to make sure you do do it yourself.
  - EraYaN 2y ago
    Not at all actually, passing hostnames means they can fully handle happy eyeballs for you and all other performance optimizations that you can do if you resolve and connect in one call.
    - ruthmarx 2y ago
      It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.
      - EraYaN 2y ago
        But you are already on their OS, so they would always be able to do that. They make the kernel, the hardware and it's firmware, so it's a moot point and needless paranoia. Might as well use the API that gives a better user experience.
        ruthmarx 2y ago
        > so it's a moot point and needless paranoia. No it's not. You are misunderstanding my point. I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely. I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPhone with the justification being safety or 'for the children' or whatever. That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.
matheusmoreira 2y ago
It's not necessarily EEE. Maybe it's just that the old wheel sucks. They want a better wheel and so they reinvented it, hopefully better this time. The corporations making proprietary software are not the only ones who have that attitude. I've resolved to make all my free software Linux-exclusive so that I can use Linux to the fullest. The Linux kernel is packed full of exclusive non-portable features that very few people take advantage of because they're obsessed with portability, POSIX compliance or whatever. I think that's a waste. Portable software is usually sucky lowest common denominator software. We should not limit ourselves to whatever glibc offers.
ryandrake 2y ago
It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.
- pram 2y ago
  OpenGL is legacy in general, its been on 4.6 for almost a decade.
- pjmlp 2y ago
  It is also legacy from Khronos point of view.