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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
