Add support for more flexible backend streams

Abierto
  • ¿Algo no está bien?
#9 4 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
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
haskell
Área
networking

Línea de trabajo

Start by reviewing HaskellNet's IMAP stream handling and the BSStreamM approach in the linked monadio branch. Compare that with the proposed conduit-based connection model and determine which direction has consensus. Done means a scoped, agreed design for flexible backend streams rather than an unresolved choice between alternatives.

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

Descripción

feature

I wanted to use IMAP with TLS and this turned out to be quite complex. (Relates to #7.) So far, I found these solutions:

  • Use threads - one for wrapping a connection into TLS and another for the actual IMAP handling. This is awful.

  • Use MonadIO instead of IO everywhere. I already tried this variant in this branch for IMAP. It seems to work well and I was able to fuse such patched IMAP with network-conduit. The main part looks like this:

    main = runTCPClient (clientSettings 143 (BS.pack "imap.centrum.cz"))
            capabilities

capabilities :: Application IO
capabilities ad = appSource ad $= f $$ appSink ad
  where
    f :: Conduit BS.ByteString IO ByteString
    f = do
            c <- connectStream conduitBSStream
            capability c >>= liftIO . print
            logout c

type BSPipe m = ConduitM ByteString ByteString m

conduitBSStream :: (Monad m) => BSStreamM (BSPipe m)
-- implementation ...

    Here BSStreamM is a (backward compatible) modification that takes an arbitrary MonadIO instead of IO. This allows us to run the whole code in Conduit instead of IO and so the actions in BSStreamM can be operations constructed using Conduit primitives. (Full example code here).

    This modification adds generality and the only loss is slightly more complex type signatures.

  • Modify HaskellNet so that it's based on conduit instead of IO. I don't have a clear picture yet. The general idea is that connection wouldn't hold a BSStream but a Sink for network output and a ResumableSource for network input. This would allow to plug in any conduit, even a pure one (for testing, for example).

I'm willing to participate on those changes, if we reach some consensus.

Lenguaje dominante
Haskell
Estrellas
92
Forks
57
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 qnikst/HaskellNet

Todos los issues de qnikst/HaskellNet

Issues similares

Más issues de Haskell

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.