[Haskell-cafe] Brainstorming on how to parse IMAP

Donn Cave donn at avvanta.com
Tue Aug 5 14:38:47 EDT 2008

Quoth John Goerzen <jgoerzen at complete.org>:
| Donn Cave wrote:
|> So I would let the application come up with the data.  In general,
| Well, your response here begs the question of how much you want to
| automate from the application.  Yes, there are multiple ways of
| communicating with IMAP servers, but you have the same synchronization
| issues with all of them.  Yes, I plan to let the application supply
| functions to read data.  But in the end, that is pointless if those
| functions can't be written in Haskell!

Sorry, I didn't entirely understand that, but the way I see it, you
might or might not be able to map the set of issues with one transport
vs. another onto some common abstraction.  And anyway it's much easier
and cleaner for you to implement the protocol parser as a pure function
of bytestring -> response, than tangle it up with I/O.  

OK, here's a trivial example of what I see as the virtues of this approach.
I don't think I actually return any size information along with my
`incomplete' failure response, but it occurs to me that I should.  Then
a graphic application can use that to start a progress indicator for
large transfers.  It will be easy for my application to update that
progress indicator, because it got the expected size and is getting the
data.  Harder to make that work through generic I/O functions invoked
inside the parser, I think.

| > I don't think there's any way to specify how much to read - I mean,
| > the counted literal certainly provides that information, but that's the
| > exception - so I would assume the application will need some kind of
| > recv(2)-like function that reads data as available.
| Exactly.  But there is no recv()-like function, except the one that
| returns IO String.  There is no recv()-like function that returns IO
| ByteString.

Well, right, that's needed.  I just hacked out my own FFI. (Likewise
for SSL.)  In a platform context where you're forced to use buffered
input semantics, you might use hGetLine and then read fixed amounts
as required for counted literals (so the parser would need to return
a bytes-needed-to-complete value to support that.)


More information about the Haskell-Cafe mailing list