Tag Archives: cURL and libcurl

cURL and libcurl, Licensing, Linux

Two fellow curl hackers

During many years I was really and truly the primary and almost single developer of curl and libcurl. Sure we’ve always got a steady stream of quality patches by contributors but I was the single guy who cared for the whole picture and who took on greater work to advance the project.

This is no longer the case. These days there are more people around that bite the really big bullets and who show that they know a lot about the internals, the protocols and have a feel and understanding for the general ideas and concepts of the project. I think they get too little attention, so I thought I’d put the light on two of our bright hackers that really are true rocks in the community:

Daniel Fandrich first appeared on the curl-library list in April 2003. More than 1500 email posts later, he’s a knowledgeable, friendly and skilled contributor in just about all areas of curl and libcurl.

Yang Tse appeared on the curl-users list in September 2005 and has somewhat specialized in cleaning up dusty corners of the code. Redoing things The Right Way, fixing compiler warnings and fixing up configure checks so that the code runs all over as it is supposed to.

These are two of our valuable committers. Ohloh.net counts 10 committers during the last 12 months, which puts us within the top 10% of all project teams on Ohloh!

But as I mentioned above, the curl development is largely built upon patches provided by people who send in one or two patches and never appear in the project again. We have over 650 named contributors and the list keeps growing at a steady pace all the time.

You can be our next contributor or even committer. Just join us and help out!

cURL and libcurl

curl feature freeze on August 10

In order to get the next curl release done, we’re entering feature freeze on Sunday August 10 (at 00:00 UTC to make it specific).

Starting then, we add no new features for the upcoming two weeks but we only fix bugs. At the end of the two week period, or possibly before that if all looks well, we release 7.19.0.

The work on CURLOPT_POSTREDIR and the “Limiting IP addresses” work can of course continue but if we don’t have working patches for them very quickly, they’ll have to wait for next release.

cURL and libcurl, Development, Linux, Network

HTTP implementations

I previously mentioned on the libcurl mailing list, that Mark Nottingham in the IETF HTTP Working Group has initiated the work on putting together an overview of all (interesting) existing HTTP implementations

Of course curl is included in the bunch, or rather libcurl, but I would also urge you all to step forward and provide further details on other implementations you worked on or know of!

Blogging, cURL and libcurl, Rockbox

Vacation days are slow days

I just wanted to drop a note saying that the biggest explanation for the silence and slowness of my blog the last couple of weeks have been my ongoing vacation, which is still going on for another two weeks.

Of course things are happening still, but due to my lack of computer time right now I tend to prioritize actually working with those things rather than posting here writing about the stuff I do/read/fix.

The Rockbox Steering Board vote is over, results will be published soon (spoiler: I’m voted in as one of the members). There’s a curl release coming up for August and we still have a few outstanding issues to fix. More on these topics later!

Open Source

“Nordic” Projects?

4 Comments

It did struck me why the idea of handing the Nordic Free Software Award to a project feels like a bad idea: Free Software projects really aren’t geographical in general.

People tend to live at a fixed location for a specific time and thus you can say that N is living in a Nordic country or not.

Free Software projects however, are not even allowed to exclude people from other places and even projects that may origin at once place or even have its largest user-base in a particular geographical spot.

Last year’s Nordic Free Software Award was handed to Skolelinux since I believe the project origins in Norway (a nordic country) and some of the leading persons in the project are Norwegian. But is that then a nordic project? I don’t want to claim that it isn’t because I honestly don’t know, but their web site certainly says nothing about it being restricted or limited to nordic countries in any significant way. If it does, I couldn’t find it.

I am the primary person and maintainer behind curl but I wouldn’t dream of calling it a “nordic” project. The trio who started Rockbox are all Swedish but calling it a nordic project would just make me laugh.

Isn’t it so, that if you can come up with a “Nordic” Free Software project that currently only lives and strives within one or more Nordic countries without spreading itself over the world, isn’t that then more likely to be a proof of a failure of said project than anything else?

cURL and libcurl

Bad Reviews Never Die

I like user feedback and comments from people in projects I participate in – even those that I run or maintain myself. I value bug reports and I think no project can evolve without a fair amount of external input.

But they can also be annoying since when done in public places they tend to stick around. If they’re negative I can respond to them if posted in forums where that is possible and where I care about it, but sometimes they’re just “blurted” out in a way that I cannot respond to and that I cannot do anything about. And the review/comment/complaint will sit there to be watched by the world. Uncommented by me or anyone else thinking otherwise.

Let me point out the recent example that made me write this particular rant: user review on curl at ohloh.

I realize there’s nobody to blame and that this is the way of life and how things work and that everybody is entitled to publish their opinions and all that. It still doesn’t feel really good when you just don’t agree with them and they’re “against” one of your own babies.

cURL and libcurl, Network, Open Source, Security

public suffixes list

I noticed the new site publicsuffix.org that has been setup by the mozilla organization in an attempt to list public suffixes for all TLDs in the world, to basically know how to prevent sites from setting cookies that would span over just about all sites under that “public suffix”.

While I can see what drives this effort and since we have the same underlying problem in curl as well, I have sympathy for the effort. Still, I dread “having to” import and support this entire list in curl only to be able to better work like the browsers in the cookie department. Also, it feels like a cat and mouse race where the list may never be complete anyway. It is doomed to lack entries, or in the worst case list “public suffixes” that aren’t any such public suffixes anymore and thus it’ll prevent sites using that suffix to properly use cookies…

There’s no word on the site if IE or Opera etc are going to join this effort.

Update: there are several people expressing doubts about the virtues of this idea. Like Patrik Fältström on DNSOP.

cURL and libcurl

curl 7.18.2 and lunch

Just minutes ago I uploaded the curl and libcurl 7.18.2 package to the curl site. There are a few new changes that people might just like, but most importantly there are many bug fixes.

And by a happy coincidence, a bunch of #curl visitors (the irc channel on freenode) are going to meet up for lunch on tuesday next week (June 10th) in Stockholm, Sweden. If you’re a curl hacker or curl fan and in the proximity that day, feel free to get in touch and join us!

cURL and libcurl

curl needs a fresh take on command line options

1 Comment

I just posted about this on the curl-users mailing list and I’ll just echo it here to reach a slightly larger audience:

One of the not so good behaviors of curl is how many of the command line options work when being repeated: toggling on/off.

We’ve got bug reports about this in the past and I know for a fact that this behavior has burnt more than one guy who’s tried to set default options for curl in their .curlrc etc. When they then re-use the same option on the command line or in a script, it effectively disables the option again…

I’d like this corrected. I want people to be able to explicitly enable and disable features with the command line options. I think the toggling is very rarely useful and something we can just abandon – unless we can figure out a way to keep it for backwards compatibility when we introduce the new behavior.

I’m willing to sacrifice some backwards compatibility to get this done, but I would of course like to hurt as few users as possible.

I’m very interested to get ideas and feedback from you guys on how we can accomplish this!

My first thoughts on how to do this, is simply to convert all the current options to enable options and then introduce a new concept that negates the option. Like -v or –verbose to enable verbose, and –no-verbose to disable verbose.

Any bright ideas?

Update: my suggestion above is what has now been committed targeted for the upcoming 7.19.0 release…