Comment by threeseed
Comment by threeseed 3 days ago
> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures.
Comment by threeseed 3 days ago
> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures.
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.
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...
> 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.
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.
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.
It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
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.
It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.