Conversation

The lack of any higher level crypto primitives in the Swift standard library seems to have resulted in people just deciding to shell out to openssl to generate a CSR, which feels like an important lesson
5
125
Replying to
This feels like not *necessarily* the wrong implementation but I’d prefer the library that shells out to OpenSSL to be part of the Swift standard library
1
1
Replying to and
Involving unnecessary CLI interfaces and parsing in both directions is far worse than using it directly. It can be used in a separate process (which does not imply any isolation without further work) without involving the CLI interface if that was actually the goal.
1
11
Replying to and
CLI brings the issue of serialization / deserialization from strings and generally it's an ad-hoc, poorly documented format rather than something structured. It's also often not a stable API. It would have to be specifically designed for automated use and use something like JSON.
1
4
Git could have been designed as CLI tools based around libraries, with those libraries eventually defining a slowly evolving versioned API usable by other applications. This is how nearly all of LLVM is built and is a major reason for it being so broadly adopted everywhere.
1
3
A neat example of this is libcurl + curl where you can pass "--libcurl output.c" as a parameter to turn your curl commands into code using the library. From there, you can properly integrate it into code without parsing CLI command output, hacking together async support, etc.
5