[Haskell-cafe] who's in charge?

[John Goerzen]

On 10/28/2010 05:44 PM, Günther Schmidt wrote:
>> There is no need for a mail client library on many platforms. Just
>> pipe the data to /usr/sbin/sendmail and poof. Done.
>>
> That would work well for sending (on Unix), but not for receiving.

Quite true.  For receiving, we have tools like fetchmail, imapsync, 
offlineimap, MH, the list goes on.

The Unix philosophy is all about pluggable bits and pieces that can be 
reused all over the place.  I like that philosophy.  It means that one 
doesn't have to reinvent mail handling n times for n languages.  As long 
as your language can do some piping, you can handle the basics of mail.

Now, I'll grant you that fetchmail won't solve every possible mail 
access scenario.  It isn't, for instance, good enough to be the backend 
of OfflineIMAP.  But I do want to push back on the notion that, on POSIX 
platforms, these things have to be reinvented for each language.  It 
just isn't so.

>> Has it occurred to you that there is no mail client library because
>> there is no need for one?
>
> No, to be honest, it never has. I absolutely cannot conceive of it. It'd
> be like not having HDBC for instance and having to roll my own database
> driver. It wouldn't have mattered how great a language haskell is, had

Hmm, I am perhaps uniquely qualified to say "been there, done that" ;-)

The existing Haskell database drivers at the time didn't meet my needs. 
  They lacked some things I considered rudimentary and standard.  I felt 
about them approximately the way you did about mail.

I decided that Haskell would be enough of a long-term win to justify 
writing HDBC.  So I did, and I'm glad of it.

I think you are getting some resistance here because you appear to be 
demanding that others volunteer their time to meet your pet need.  This 
attitude doesn't usually work.

> it not had HDBC I would have had no choice but to drop it and move on.

Or you could have written HDBC.  Or you could have used unixODBC, which 
already solved that problem.  (Whoops, did I do a tiny bit of wheel 
reinvention myself?  Indeed I did, with the PostgreSQL HDBC backend. 
There are reasons for it though.)

> Database connectivity to me is one of the essential things I need to be
> able to do, and so is email, as is xml, as is http.

HTTP is another thing that can easily be "outsourced".  I've been 
somewhat unhappy at various points in time with the Haskell HTTP 
libraries.  No problem, though; there's always Curl.  One can choose the 
Haskell libcurl binding or call the Curl binary directly; it's even 
portable to all sorts of platforms, and you get not just HTTP, but FTP, 
Gopher, SCP, and some other useful protocols along for the ride.

> Well it's not necessarily only about sending mail, it's more about the
> whole shebang one wants / needs to do with mail.

So if it's not about sending, it's about receiving or accessing stored mail.

The Maildir spec is very simple and easily implemented.  Google tells me 
there is an implementation in xmonad already.  Tools to get mail into 
Maildirs are plentiful and featureful.

My point is this: using existing tools on your system, and turning a 
blind eye to their implementation language, can be a perfectly workable, 
and even elegant, solution.

Example: say you needed to copy a directory containing files and 
directories.  Is that easy to do?  You could probably whip up some sort 
of recursive file copying thing to do that in a few lines of code.  But 
will it handle things like preserving permissions bits, ownership, ACLs, 
symbolic links, not following symlinks, etc. correctly?  We already have 
a tool that does all those things (cp -a), so using it is, in my book, 
more elegant than writing a (probably more buggy and certainly less 
tested) clone.

So I'm pushing back on your unstated premise; namely, that a Haskell 
library for mail handling is necessary for efficient mail handling in 
Haskell.  I don't think it is.

-- John