SSWG - August 2nd 2023

Server Workgroup Updates
1

Attendees:

Previous Meeting Action Items

  • Swiftly - just waiting on the website and release build, :a: @adam-fowler to chase
  • @adam-fowler to open a PR on the package index to tag incubated projects - :a: carry over
  • @tomerd to poke internally about the yearly blog post - :a: carry over
  • @0xTim Github CodeQL forum post (added to Vapor, need to do forum post) - CodeQL Updates:white_check_mark:
  • @graskind build GitHub action for generating the dependency graph, to be used by CodeQL et al - :a: carry over
  • NIOResumableUpload - PR is here :white_check_mark:
  • Publish meeting notes - all

Core Team Meeting

Dependabot

  • Now creating issues, security emails and PRs
  • Is it worth a blog post/forum post?
  • @0xTim to create rough draft

DiscordBM

  • @FranzBusch to be review manager
    • Will post to forums :a:
  • The SSWG have guidelines for how to run the review and make sure the pitch is good for review

HTTPServer

  • NIO side almost ready
  • H2 example written
  • Need to start trying out the API

WebAuthn

  • ready to tag a 1.0.0-beta
  • Just needs some more eyes

Swift Metrics

Swift Foundation Workgroup

  • First meeting in a couple of weeks
  • Forward any questions to @adam-fowler

Maturity Review

  • Needs to be published
  • Lots of pitches to be written, working through them
  • Web frameworks to create pitch and submitting pitches together
  • SQLite Proposal - @ktoso to run the pitch, need to discuss what level to be run at
  • @FranzBusch to update the guidelines to better reflect the desire to use Swift Concurrency exclusively :a:
  • @0xTim to update GitHub - swift-server/sswg-collection :a:
3 Likes
2

can i ask why we should found yet another independent package repository, especially when the proposed API doesn‘t introduce any build dependencies?

“package-level” API is not really something that is meaningful in swift today, and concerns about module-level bloat are better addressed by spinning off the additional API into separate modules and library products.

the most commonly-used documentation tool today, DocC, has no support whatsoever for multi-target documentation, much less multi-package documentation. today we are able to navigate laterally across DocC modules in the same package on the swift package index thanks to the heroics of @daveverwer and @finestructure , but these bridges do not cross package boundaries, and i feel like fragmenting the server libraries further will make an already hard-to-navigate constellation of libraries even more difficult to use.

3 Likes