Add support for more flexible backend streams

未关闭
  • 哪里不对？
#9 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
haskell
领域
networking

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Haskell
星标
92
派生
57
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

qnikst/HaskellNet 的其他 Issue

查看 qnikst/HaskellNet 的全部 Issue

相似的 Issue

更多 Haskell Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。