curl-users
Re: An idea on separate options for different URLs
Date: Sun, 1 Aug 2004 00:19:28 -0700
On 7/31/04 11:09 PM +0200, Daniel Stenberg wrote on An idea on separate
options for different URLs
>Hi
Hi, Daniel. Since the day seems to be just about over and no seems to be
offering opinions I thought I might as well make my usual stab at looking
foolish.
>I would like to enhance the tool curl to make it able to deal with options set
>to specific URLs, so that we can make multiple requests easily, using a single
>command line (and thus use persistent connections etc).
Just make sure I'm on the same page - the crux of the issue is being able
to operate through a persistent connection by what ever means is deemed to
be the most sensible, right?
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. Adding more functions, perhaps each
with their own burden of long winded options, would exacerbate any buffer
size related problems that might be waiting to crop up. Additionally, it
serves as a means of "noisifying" the command even more. At least for my
poor old addled grey matter, stringing in even more stuff to consider in
the presence of shell escape oddities and the like sounds like a recipe for
trouble.
My knowledge of persistent connections is a great deal less than my piteous
little knowledge of curl but looking at some quick research points me in a
different direction. Apparently, the idea is that a single TCP connection
is established to do multiple activities at a site (and I only see HTTP
being discussed in the literature I read). It seems to me the problem is
one of setting up such a connection and then identifying it as the
connection to use in subsequent operations. There is a "heartbeat/timeout"
aspect to persistent connections that could mean that one might not have to
manage the closure of the connection specifically which would make leaving
a connection up across shell command boundaries not necessarily a really
bad thing.
So, assuming I'm not completely out to lunch here one might hypothesize
three options to curl. One would be used to set up the persistent
connection and associate some kind of identifier with it (the proper means
to do this eludes me but perhaps an entry in a /var/run sort of file???).
Another (perhaps the same one as mentioned previously - which might have
some advantage in reestablishing a persistent connection in the event one
is lost) would be used to issue further transfers on the connection.
Finally a third one would be used to specifically close a persistent
connection if it were open.
>I'm interested in your feedback!
As they used to say on TV - You Asked For It! ;-)
-- Walter M. Pawley <walt_at_wump.org> Wump Research & Company 676 River Bend Road, Roseburg, OR 97470 541-672-8975Received on 2004-08-01