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
