Hi Guys,

> > 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...

I was just wondering if anyone had any more thoughts after Daniel's email on
the 12th and mine from the 11th.

> > 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 guess this could only be done if everything after the OK was sent through
as body data but to be honest I don't think this is the right approach as a
transfer would still be required for certain commands and not for others.

> 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.

I guess we can:

1) Implement each command using a unique URL as per my original email from
the 1st.

2) Break the commands down into three categories as follows and use a URL
for each category:

Information type commands (LIST, UIDL, CAPA and STAT)
Retrieve type commands (RETR and TOP)
Instruction based commands (NOOP, DELE, RSET)

3) Try and keep the existing two formats:

Message based commands (LIST, UIDL, RETR, TOP and DELE)
Non Message based commands (LIST, UIDL, CAPA, STAT, NOOP and RSET)

The problem we've seen with option 3 is it isn't possible write a generic
handler that is command agnostic as different commands return different
amounts of data that may or may not require a transfer to be instigated. For
example OK or OK followed by information no not require a transfer but OK
and a multiline response or OK followed by information and a multiline
response do.

Even with option 2, where RETR and TOP return OK followed by multiple lines
of data and NOOP, DELE and RSET simply return OK, the problem is that LIST
and UIDL will return OK followed by information when a message id is
specified but will return OK followed by both information and multiline of
data when a message id is not specified, yet CAPA returns multiple lines of
data after the OK and STAT simply returns information.

Obviously anything that is received after the OK can be sent to the client
as HEADER data rather than as BODY.

> 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.

I don't have any qualms about this - but does anyone else? To this degree,
anything that is in the final part of the path can just be sent to the
server as is (after being URL decoded of course!)

I would like to try and finish this off over the Christmas period and get
the changes into the next release if possible - Does everyone think that is
doable?

Additionally, is it possible to push patches 1 and 2 from my patch set of
the 10th as they are simple tidy up type patches in readiness for the
changes? Even if I rework my change based on more feedback I will take the
opportunity to tidy the code up again so it is consistent ;-)

Cheers

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-21