# SSWG - August 2nd 2023

**URL:** <https://forums.swift.org/t/sswg-august-2nd-2023/67268>\
**Category:** Workgroup Updates\
**Tags:** sswg-meeting-notes\
**Created:** [September 13, 2023, 9:07pm UTC](https://forums.swift.org/t/sswg-august-2nd-2023/67268 "2023-09-13T21:07:02Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![0xTim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/0xtim/32/27968_2.png) [@0xTim](https://forums.swift.org/u/0xTim)\
**Post date:** [September 13, 2023, 9:07pm UTC](https://forums.swift.org/t/sswg-august-2nd-2023/67268/1 "2023-09-13T21:07:02Z")

</div>

## Attendees:

- @0xTim
- @adam-fowler
- @FranzBusch
- @Joannis_Orlandos
- @tachyonics
- @tomerd

## Previous Meeting Action Items

- Swiftly - just waiting on the website and release build, 🅰 @adam-fowler to chase
- [@adam-fowler](https://forums.swift.org/u/adam-fowler) to open a PR on the package index to tag incubated projects - 🅰 carry over
- [@tomerd](https://forums.swift.org/u/tomerd) to poke internally about the yearly blog post - 🅰 carry over
- [@0xTim](https://forums.swift.org/u/0xtim) Github CodeQL forum post (added to Vapor, need to do forum post) - [CodeQL Updates](https://forums.swift.org/t/codeql-updates/66540)✅
- [@graskind](https://forums.swift.org/u/graskind) build GitHub action for generating the dependency graph, to be used by CodeQL et al - 🅰 carry over
- NIOResumableUpload - PR is [here](https://github.com/apple/swift-nio-extras/pull/203) ✅
- Publish meeting notes - all

## Core Team Meeting

- Slides created
- @FranzBusch to add some slides

## 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 🅰

- 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

- New PR for a metrics handler - [Add RewritingMetricsHandler by hamzahrmalik · Pull Request #136 · apple/swift-metrics · GitHub](https://github.com/apple/swift-metrics/pull/136)
- @tomerd mentions it should probably live in [GitHub - apple/swift-metrics-extras](https://github.com/apple/swift-metrics-extras) to avoid bloating the API, especially as a lower level package

## 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 🅰
- @0xTim to update [GitHub - swift-server/sswg-collection](https://github.com/swift-server/sswg-collection) 🅰

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 13, 2023, 9:49pm UTC](https://forums.swift.org/t/sswg-august-2nd-2023/67268/2 "2023-09-13T21:49:35Z")

</div>

> [@0xTim](#):
>
> - New PR for a metrics handler - [Add RewritingMetricsHandler by hamzahrmalik · Pull Request #136 · apple/swift-metrics · GitHub](https://github.com/apple/swift-metrics/pull/136)
> - @tomerd mentions it should probably live in [GitHub - apple/swift-metrics-extras](https://github.com/apple/swift-metrics-extras) to avoid bloating the API, especially as a lower level package

can i ask why we should found _yet another_ independent package repository, especially when the proposed API [doesn‘t introduce any build dependencies](https://forums.swift.org/t/announcing-swift-http-types/66088/8)?

“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.