Hello, I am considering starting work on a pipes-based IMAP client, partly because I am in need of an IMAP client and partly because I'd like to get more familiar with the pipes library and make a contribution to the pipes ecosystem. However, before I start in earnest, I'd like to ask a couple of questions of the community so that I don't head down the wrong road before I even start!
First, is anybody working on something similar already? Second: there exists a non-pipes library, "HaskellNet"[1], which supports IMAP as well as SMTP and POP. It also supports TLS through the (poorly-named) "HaskellNet-SSL" helper library I wrote last time I needed IMAP functionality [2]. Development of this library is fairly quiet, though the maintainer is generally quick to reply to issues and pull requests left on the github page. The functionality the library supports is quite low-level, giving types to many of the protocol's commands so you don't have to construct the strings manually, but not doing much beyond that. It is based upon a "BSStream" abstraction which allows you to control how data is streamed in and out (this is how I implemented the HaskellNet-SSL wrapper). There was also some discussion nearly a year ago on the HaskellNet issues page regarding support for conduit or other backend streams[3]. As far as I can tell no pull request has come of it as yet. The question is, should I try and take an approach similar to pipes-http, i.e. modify HaskellNet so that it is easier to plug in pipes/conduit/whatever and then write a lightweight pipes layer over that, or should I just write my own implementation making full use of the pipes ecosystem (pipes-network, pipes-network-tls, and pipes-attoparsec all seem like they would be handy for this sort of thing), and develop it entirely separately from the HaskellNet stuff? I have been slightly leaning towards the latter, because that would let me get my hands dirty with pipes stuff a bit more and also allow me to approach the design from a purely pipes mindset. However, given that the extraction of http-client into a library that can be used by both pipes and conduit seems to be quite a success, and that HaskellNet seems to be the incumbent IMAP implementation, I don't want to fracture the ecosystem just for the sake of it. There is a third option, I suppose, which is to write my own IMAP client, but make it neutral like http-client so that it could be used by either conduit or pipes. Clearly this would only be worthwhile if there was some issue with HaskellNet which made it unsuitable for that purpose. I haven't investigated deeply enough to determine whether that is the case. Any opinions / ideas welcome -- as I say I am really just starting with this so am open to investigating whichever direction seems most appropriate. Thanks, Dani. [1]: https://hackage.haskell.org/package/HaskellNet [2]: https://hackage.haskell.org/package/HaskellNet-SSL [3]: https://github.com/jtdaugherty/HaskellNet/issues/9 -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
