Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Provide a "minimal" version of makeDefaultOptions for libraries

Abierto
  • ¿Algo no está bien?
#95 13 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
swift
Área
api

Línea de trabajo

Comienza con el protocolo HTTPClient y su API makeDefaultOptions existente; después, revisa cómo se definen los protocolos RequestOptions y las implementaciones concretas de clientes en esta propuesta. Compara los comportamientos mínimos y recomendados propuestos, y considera el issue completo solo cuando se hayan acordado y documentado la forma de la API y la semántica de las funcionalidades predeterminadas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

http-client

I think we need a "minimal" variant of makeDefaultOptions (the way to create new options from a library, when you don't know which concrete HTTP client implementation you're using). Because as a library, you can't afford to have the client arbitrarily choose to enable various features you're a) not aware of and b) aren't expecting. For example, if there's a "Batching" feature, represented by a protocol like:

protocol BatchingOptions: RequestOptions {
    /// Defines the batch of body bytes that are filled up before being sent.
    var batchSize: Int64?
}

This could be a useful optimization, but always needs to be opt-in. Either by you using a known concrete client, or you requesting that feature through the protocol constraint:

func makeAnHTTPCall<Client: HTTPClient>(client: Client) where Client.RequestOptions: BatchingOptions async throws {
    var options = client.makeDefaultOptions()
    options.batchSize = 4096
    try await client.perform(request, options: options) {

    }
}

However, if you don't request it, and your library looks like this:

func makeAnHTTPCall<Client: HTTPClient>(client: Client) async throws {
    var options = client.makeDefaultOptions()
    try await client.perform(request, options: options) {

    }
}

Then client.makeDefaultOptions() absolutely must have batchSize = nil, otherwise the library won't work correctly with bidi streaming, as bytes will be held back until reaching the batch size, but the library has no way of learning or fixing that, without explicitly requiring that feature just to turn it off.

So if we assume that the set of options protocols will be open, and community libraries will be able to add additional ones, and the set of HTTP client implementations will also be an open set, it means that "default options" must mean "features disabled", and libraries will only enable those that they need by explicitly requesting that protocol and enabling them.

Now, some features are on/off, such as this batching example, and we can easily require that "default options" turns it off. However for other features that can't really negatively affect a library's observable behavior, we can still discuss what "on" vs "off" means. For example, I'd argue it's fine if the default value for "HTTP versions supported" is "all", even though some folks could consider that "on". Maybe that means we should re-spell that feature as "Subset of HTTP versions requested", so not allowing an HTTP version would be considered "on" for that feature.

This is why I think we need another variant of "default options" that makes it clear that it's not "nice-to-have, recommended options" (which is useful for applications, and can still exist e.g. under the name "recommended"), but must be "all features as disabled as they can be" (which is the only way to make behavior predictable to libraries, here called "minimal").

Maybe the simplest spelling that still allows this is:

protocol HTTPClient {

    // associated types

    func makeRecommendedOptions() -> RequestOptions
    func makeMinimalOptions() -> RequestOptions

    // perform method
}

So applications and concrete client utils would default to recommended, while libraries would always start with minimal (though I don't like the name, so please suggest a better one).

Lenguaje dominante
Swift
Estrellas
70
Forks
24
Merge medio
9 h 31 min
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apple/swift-http-api-proposal

Todos los issues de apple/swift-http-api-proposal

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.