On Mon, 12 Feb 2007, Dan Fandrich wrote:

> Fixing telnet support so it doesn't rely on stdin/stdout has been on the
> TODO list for ages. Fixing that seems like the better solution.

I wholeheartedly agree. The telnet situation is pretty miserable as it is
right now.

> And on that topic, what kind of solutions have been proposed for fixing
> telnet? I don't recall hearing any in a long time, if ever. I suppose it's
> not quite enough to simply use the CURLOPT_READFUNCTION and
> CURLOPT_WRITEFUNCTION callback to read/write data instead of stdin/stdout.

Nope, those are designed for content that is more or less already there to
send or retrieve. They don't really work for the telnet kind of situation
where an application just wants to send a little chunk every now and then.

> After all, data could come from either side at any time and you can't have
> either the library or the application blocking while data from the other
> side is ready to come or go. Is it reasonable to restrict use of telnet to
> the multi interface to get around this?

Yes, I think it would be reasonable, but limiting it to the multi interface
wouldn't suffice, we still lack proper internal support.

Currently, when libcurl wants to send something to the remote peer it will
check if the socket is "ready for writing" and then call the read callback to
get data to send. In a TELNET case, it might be ready for rather long times
without the application wanting to send anything so the app must have a way to
do "flow control", a way to say "I don't want to send anything for the moment"
and then have the uploading disabled until it is again enabled.

Since this has been in the TODO for ages without anything caring enough, and I
honestly don't think TELNET is very widely used, I'm not totally against the
idea of simply disabling TELNET support until the code gets fixed (which very
well could take a long time), and then we could fix the poll() on mac issue at
the same time...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html