On Sun, 27 May 2012, William Betts wrote:

> I didn't realize that you could set the helo string like that! I guess there
> isn't much benefit to it other than I think it looks better. If I had a
> choice between the two I'd rather use the CURLOPT_MAIL_HELO option. To me it
> stands out better as to what it does.

But since we now support the path approach it really doesn't make much sense
to add a second way to provide the same information - the previous supported
method would still need to be kept...

> I'd also like to add in a header and a body option. Those options in my
> opinion would make it easier to send customized email.

libcurl already allows you to provide whatever you want in the mail. I don't
think it needs two new ways to offer the same functionality... unless perhaps
if they somehow provide new abilities or features users would like. So feel
free to elaborate on what more exactly you're suggesting!

> I might be wrong, but from what I've seen the standard way to send the
> actual body with headers appears to be reading a file in or using a
> callback.

Yes, that's how it gets done. If not with a callback, how would you pass in
this information to libcurl?

> I mainly use libcurl with PHP so my line of thought might not really be
> aligned with that of people who use it with C/C++.

We all have certain objective and goals with what we work on in libcurl. I
doubt there are two of us having the same set. That's however not a valid
reason for introducing things that aren't "kosher" libcurl stuff.

PHP/CURL is an entire layer on top of libcurl and if you want new fancy things
in there you can add them there without them affecting libcurl at all. In
fact, you can probably even add them on top of PHP/CURL without affecting that
extension either in the case of these header and body options.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html