On Sat, 10 Dec 2011, Dan Fandrich wrote:

> It sounds from the description above that this patch uses -X not to replace
> one command with another as sent over the wire, but to actually change
> curl's behaviour by changing the type of transfer performed. It might turn
> out that this approach is the right one for POP-3, but I think that needs to
> be debated some more.

I too sense the difference in nature this introduces and I'm not sure it is a
good thing. I can't say I'm totally opposed it either...

> It turns out that all those five new commands (and probably most others)
> follow one of two patterns: the command returns with only a response code,
> or it returns with a response code and a multiline response.

Right, it is very unfortunate that we can't seem to do a generic parser for
pop3 responses due to this.

I would still prefer that custom commands are sent as generic quote commands
that are agnostic to what the actual meaning of the command is, and that
function could possibly know a set of commands' response variations, and/or
then we implement some additional way to tell libcurl about how to deal with
the response to a particular command. Like another modifier before the
command, like [multi] or [single] or another magic string that can't legally
be a part of a true POP3 command.

> Since a normal message retrieval (RETR) returns a response code (*) and a
> multiline response, any other POP-3 command that returns something similar
> should be able to be replaced and work correctly. So, implementing TOP (and
> all other similar POP-3 commands, like UIDL) should work by using a normal
> message URL (which normally sends an RETR) and -X TOP to send TOP instead
> (** there's an important gotcha discussed later).

Regarding the "gotcha" about TOP (as an example) requiring more than one
argument. Is there a reason we can't just provide them in the URL
space-separated?

Like "curl -X TOP pop3://example.com/FOO%20BAR" would send "TOP FOO BAR"
instead of RETR.

> * The first issue is that some commands return valuable information in the
> response code line. I'm not sure if curl implements it or not yet (looks
> like not yet), but this could be simply returned in CURLOPT_ERRORBUFFER (I
> think that's the one) for use by the application.

That works for the error case, yes, but not for positive responses. In those
cases we've previously told FTP client authors to use the header callback and
interpret the responses - it has the downside that the client needs to
implement very specific protocol knowledge. But I still think that is actually
less ugly than somehow sending the data from a respone header as faked body
data, as it would still require that the client program knows exactly what is
sent as a response to such a command.

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