In the preparations to support secure connections (SSL) with Swiftfire, SwifterSockets was released as the first package that was rewritten specifically for this purpose.
Two pretty large changes will be apparent to current users: First is the move to distribute SwifterSockets as a package.
Move to Swift Package Manager
No longer are all the functions defined as static functions in a class, but they are now normal functions inside a package cq framework.
When using the Swift Package Manager (SPM) the SwifterSockets package can be specified as a dependency.
When using Xcode, the framework that can be build (with the enclosed xcode project) can be imported under “Embedded Binaries” of the project that needs it.
In both situations, the functions available in SwifterSockets can be called through the “import SwifterSockets” declaration.
Prepared for SecureSockets
The secure socket layer bring additional complexities that have been adressed by introducing a Server class and a Connection class.
Connections are abstractions of a transfer mechanism that can send data to and receive from a peer. In SwifterSockets this will always be a Tcp/Ip peer. In SecureSockets the same class will be used for SSL connections.
Connection is a new class provided by SwifterSockets that an API user can inherit from to implement connectivity operations (receive/transmit/close).
Rather than trying to offer the API user a variety of threading options, this approach has been dropped and is replaced by a fully functional Server class. Like the Connection the API user can inherit from the Server class, or use it directly.
To read more about this, see the User Manual at github.