Walt Pawley wrote:

>On 8/2/04 10:24 AM +0200, Daniel Stenberg wrote on Re: An idea on separate
>options for different URLs
>
>
>
>>>Assuming that's true, I don't see the real value of putting more stuff on
>>>"one line". It's not all that uncommon to see people resorting to multi-line
>>>continued curl commands now.
>>>
>>>
>>Quite true. But persistent connections _require_ the transfers to be done on a
>>single command line.
>>
>>
>Is it really "single command line" or single process too have the
>association with the connection's socket? If it's the latter, perhaps one
>could launch a curlpc helper app and use it's PID as the identifier.
>
>Then multi-line scripts could use a persistent connection, I think. I'm
>really too ignorant to be discussing these things and just have a small
>exposure of the concepts involved.
>
>
That could be achieved something like this:

    curl --persist /tmp/named.pipe [....] http://some.domain.com
    curl --persist /tmp/named.pipe [....] http://some.domain.com/xxx.html
    curl --persist /tmp/named.pipe [....] http://some.domain.com/yyy.html

If the named pipe exists and is being read by the helper process, just
write the command line to it and have the helper process it as if it
were a real command line. If not, spawn the helper process, then write
to the pipe. Probably need a second named pipe to read back results - I
don't think those things are bidirectional. Also probably need a bit of
handshake to make sure it really is a curl helper currently holding the
pipe open.

I'm not sure I'd have a use for such a thing, though. Most of the time,
I'm pinging a lot of individual servers, rather than conversing with a
single server.

Ralph Mitchell
Received on 2004-08-03