cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: memory leak goes, new perl interface comes

From: Georg Horn <horn_at_koblenz-net.de>
Date: Wed, 11 Oct 2000 11:31:52 +0200

On Wed, Oct 11, 2000 at 12:05:05AM +0200, Daniel Stenberg wrote:

> May I suggest you put a version number in the file name? ;-) It'll make it
> easier to track new versions.

Really? ;-) Ok, i'll try that...

> Got any massive floods of feedback yet?

Nope. But at least it has been downloaded a few times, as i saw from the server
log.

> > Registering callback-functions and passing lists for options HTTPHEADER
> > and HTTPPOST still does not work
>
> You could probably add some functions that allow such stuff to get added,
> that return some kind of handle to the list and then you pass that handle on
> later.

I thought that maybe some perl hackers were here and could add this...
The linked lists shouldn't be to hard, but the callbacks are not so easy...

> If you get a 7.4 pre-release you'll see how libcurl will offer that
> functionality in the upcoming release.

Ok, i'll have a look at it.

> I'll try to briefly explain why you can't at the moment: nobody wanted it
> that bad.

Well, i can live with the momentary state by storing the downloaded url to
a file and reading from that file, but for my special purpose it would be nice
to read directly from a filedescriptor: I have a script that downloads html
pages and parses the html code. This is done by the perl module
HTML::TokeParser (from CPAN) that works like the following:

my $p = HTML::TokeParser->new($file_or_doc);
while (my $token = $p->get_token) {
    do_womething_with_token();
}

For $file_or_doc you can pass in either a filedescriptor or a filename.
(Ok, you can also pass in the whole document as a large string...)

> There are several benefits with a design like that, but there are several
> drawbacks as well. Curl will not be able to have all these nifty features in
> the low-level interface. Things that the easy-functions do automatically
> (like following Location:) would have to be done by the users of the
> low-level interface.

Yes, curl has lots of nice and comfortable features, but i think the lib should
also (note: "also", not "only") provide a low level interface that gives
programmers the ability to fully control things themselves. I indeed use the
follow-Location: feature of curl in this case, but i wouldn't mind parsing the
headers by myself.

> No. You can do whatever you please with it. You can write it to a file, sure,
> but you could just as well copy it to a buffer, add it to a linked list of
> your choice or whatever.

Ok, i could define a write callback, copy all the data into a large buffer,
and at the end pass this buffer into my parser, but it's more overhead and
not so straightforward.

> The only difference here is that you'll get called instead of simply read out
> the data yourself. You can very well process the data as soon as you get it.

Yes, at the bottomline that's the only difference, but it's a different
kind of programming, and i like more to call a function if i need data, and not
to be called if something is there. ;-) Also, i just asekd if it would be
possible...

> In one word: "multi-threading". The errno is already in trouble for threads.
> Globals are impossible.

Who the hell invented these blody threads? ;-)

> Thanks for your work and your comments. I really appriciate ideas and
> constructive criticism. I'm dependent on feedback.

No problem, just my ten pence...

Georg
Received on 2000-10-11