On Mon, 28 May 2012, Steve Holme wrote:

>> With the patches it will still work the other way as well so nothing would
>> be broke.
>
> My own opinion is that I think an option like you suggested is a lot cleaner
> (although I would recommend a better name as it would be used by both EHLO
> and HELO commands and really represents the client address / hostname) and
> like I said in my previous email, passing this address in the URL is a bit
> of a hack. However I didn't write the original SMTP implementation for curl
> and as such we are where we are - I can only thank those that did write it
> as it was a good starting point! However, we *might* want to consider
> replacing the URL with a CURLOPT_MAIL_CLIENT option for a major update in
> curl such as v8.00 ;-)

I could agree with that.

I'm the one who did the original SMTP implementation and I also did the IMAP
and POP3 ones at the same time and I took the "get the value from the path"
shortcut only to avoid having to add three (or more) new options. In
hindsight, that was perhaps not a very good idea but then I also don't think
it is that terrible. I think we can live with it. And I don't want to
introduce a new way that only provides the same functionality we already have.

At times I think about the minor number 27 which is what the next release is
going to use, and if we should attempt to even that out with a clean v8
release at some point in time. It's soon 12 years since version 7.1 was
released.

But then I remember how upset users got the last time we modified the ABI only
a little and I realize that we don't yet have any significant hurdle or design
flaw that requires a clean start and so I bury that idea again and keep
bumping the minor number... The bitwise number define logic in curl/curlver.h
will prevent us from a minor number above 255 though! =)

> As you already mentioned I wouldn't recommend using the file mechanism for
> medium or large scale applications. The callbacks however do work very well
> and allow you the programmer to either pass data to libcurl from memory or
> by reading a file a block at a time - for other protocols that may accept
> large files sending a block at a time is very important. With SMTP it is a
> little more tricky as files have to be encoded and may have to be split
> across several messages.

If you use libcurl for doing multiple protocols within an application, that
single way of providing data is probably handy and brings consistency.

> However, I have considered implementing the data sending similar to HTTP and
> have the header and body sent separately. You could then specify all the
> headers, such as To, From, Subject, Date, Content-Type etc... as you would
> for a HTTP upload. However, the problem here (as I see it. mainly because I
> don't know the HTTP protocol too well) is that an email can have a header
> and a body, that body then can contain sub messages which themselves can
> have a header and a body. Those sub messages can also contain sub messages
> which again have a header and body :-(

Yeah, that kind of recursive levels of headers and bodies makes it a bit...
tricky. In HTTP land, the corresponding concept would be multipart formposts,
and libcurl support sending such ones with curl_formadd() - which creates a
linked list of data that libcurl understands and can deal with.

I could imagine that a similar approach could be made for building a complex
SMTP structure as well.

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