Add support for more flexible backend streams

Aperta
  • Qualcosa non va?
#9 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
haskell
Ambito
networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Haskell
Stelle
92
Fork
57
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di qnikst/HaskellNet

Tutte le issue di qnikst/HaskellNet

Issue simili

Altre issue su Haskell

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.