The Server APIs Work Group is responsible for steering the Swift Server APIs project, which is an evolving set of Swift libraries developed as part of the Swift open source project to provide fundamental capabilities for building server-oriented software.
The work group consisting of a core team, stakeholders from the server-side Swift community, and anyone who wants to get involved. The work group consists of three roles: core team member, stakeholder and contributor. Participants may have more than one role in the work group.
Everyone is welcome to contribute to the Server APIs Work Group through participating in a range of activities including joining as a stakeholder, participating in design discussions, asking or answering questions on the mailing lists, reporting or triaging bugs or by submitting pull requests to the project(s) for implementation or tests.
The work group is initially focussing on the creation of API proposals for base networking, security/encryption and HTTP parsing:
-
Base Networking: Provide a portable interface for low level socket based network based I/O, including TCP/IP and UDP protocols, IPv4 and IPv6 support and domain name resolution. Support should be provided to create and use both synchronous and asynchronous non-blocking connections.
-
Security and Encryption: Provide common cryptographic constants and cyphers along with keychain and certificate management, and SSL/TLS based secure transport. This must integrate with the base networking support to provide secure sockets, and with the HTTP parsing library to provide HTTPS support.
-
HTTP and WebSockets: Provide low level HTTP parsing, including HTTP, HTTP/2 and WebSocket support making it possible, in conjunction with the security and networking APIs, to create secure HTTP and WebSocket servers.
Analogous to the primary Core Team for Swift, the work group has a steering team that is responsible for providing overall technical direction, ensuring co-ordination both between the various API efforts (for example around Network, Security and HTTP integration for HTTPS) and with the wider Swift Core Libraries and language. Membership of the steering team is contribution based and is expected to evolve over time.
The initial steering team consists of:
- Chris Bailey (@seabaylea, IBM Kitura)
- Logan Wright (@LoganWright, Vapor)
- Paulo Faria (@paulofaria, Zewo)
- Steve Algernon (@salgernon, Apple)
The work group also has stakeholders who represent server-side frameworks or applications. They are responsible for providing early input on use cases and API design as part of the iterative design and implementation process, and to adopt the new APIs into their frameworks.
Joining and leaving the work group as a stakeholder is a straightforward process. The only requirement is to raise a Pull Request to add or remove your name from the stakeholder list in this project, which will act to add or remove you from invites to formal work group discussions.
The initial stakeholders consists of (alphabetically):
- Ah Shone (@tasktinkle, Baidu)
- Alex Blewitt (@alblue, Apple)
- Alfredo Delli Bovi (@adellibovi)
- Andrew Dunn (@Andrew-Dunn)
- Bas Broek (@basthomas)
- Ben Cohen (@airspeedswift, Apple)
- Billy Tobon (@billyto, Rent the Runway)
- Carl Brown (@carlbrown, IBM)
- Cătălin Stan (@thecatalinstan, Criollo)
- Damian Kolakowski (@glock45, Swifter & swiftx)
- Dan Appel (@danappelxx, Zewo)
- Daniel Dunbar (@ddunbar, Apple)
- Danielle Tomlinson (@dantoml, Jay & Other OSS)
- David Ask (@davidask, Zewo)
- David Sperling (@dsperling, Smith Micro)
- Eleftherios Laskaridis (@laskaridis, eTravel)
- Emanuel Guerrero (@eman6576)
- Farzad Nazifi (@euwars, boon)
- Gelareh Taban (@gtaban, IBM)
- Gianluca Tranchedone (@gtranchedone)
- Gregor Milos (@gmilos, Apple)
- Gwynne Raskind (@gwynne)
- Ian Partridge (@ianpartridge, IBM)
- J. Morgan Lieberthal (@baberthal)
- Jack Lawrence (@jackhl, Apple)
- Jacopo Andrea Giola (@JGiola)
- Jason Toffaletti (@toffaletti, Apple)
- Joannis Orlandos (@joannis, OpenKitten)
- Johannes Weiß (@weissi, Apple)
- John Lin (@johnlinvc)
- Jonathan Thornton (@jonblatho, Loop Weather Services)
- Kelvin Çobanaj (@kelvincobanaj)
- Kuan Huang (@widehuang, Baidu)
- Kyle Jessup (@kjessup, Perfect)
- Laurent Gaches(@lgaches)
- Marcin Kliks (@vi4m, Zewo)
- Max Desiatov (@explicitcall, Astrocat)
- Maxim Veksler (@maximveksler, Sugar So What)
- Ludovic Dewailly (@ldewailly, Apple)
- Luke Hiesterman (@gravisman, Apple)
- Marc Hoffman (@dwarfland, RemObjects Software, Elements Compiler)
- Michael Chiu (@michael-yuji, SX0)
- Nic Jackson (@nicholasjackson, notonthehighstreet.com)
- Patrick Bohrer (@pbohrer, IBM)
- Phil J. Łaszkowicz (@siilime, Omnijar Studio)
- Piers Mainwaring (@piersadrian)
- Ricardo Borelli (@rabc, Zewo)
- Rick Mann (@jetforme, Latency: Zero, LLC)
- Robert Dickerson (@rfdickerson, IBM Kitura)
- Robert Payne (@robertjpayne, Zewo)
- Ryan Collins (@rymcol)
- Sahand Nayebaziz (@sahandnayebaziz, Hypertext)
- Sam Liu (@ontouchstart)
- Sasha Milic (@SashaMilic, OpenRatio)
- Scott Lessans (@slessans, Nourish Technology)
- Stevey Brown (@Steveybrown)
- Tanner Nelson (@tannernelson, Vapor)
- Thiago Holanda (@unnamedd, Zewo)
- Thomas Catterall (@swizzlr)
- Thomas Paul Mann (@thomaspaulmann, Swish)
- Tim Burks (@timburks, Google)
- Tom Doron (@tomerd, Apple)
- Tripta Gupta (@neurosaurus, Capital One)
- Tyler Cloutier (@cloutiertyler, Edge)
- Tyler Stromberg (@AquaGeek)
- Veck Hsiao (@fbukevin, Sanity)
- Wassim Seifeddine (@wassimseif)
- Yuki Takei (@noppoMan, Slimane)
More information can be found in the Server APIs pages of swift.org, or by posting to the swift-server-dev mailing list.