Comments inline below:
On 5/12/14, 4:24 PM, Daniel P. Wright wrote:
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?
Not that I'm aware of.
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.
Very few people use the `HaskellNet` library, so there's not much of an
ecosystem to fracture.
What really matters is whatever you enjoy doing the most. Your
productivity will be much higher if you are doing it for yourself rather
than others.
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
--
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].
