On Mon, 9 Jan 2012, Mark Schafer wrote:

(Since this subject is about libcurl it might be better held on the
curl-library mailing list. I'm CC'ing my response over there as well for info
at least. Mark's original post is here:
http://curl.haxx.se/mail/archive-2012-01/0007.html)

> In my recent attempt (failed) to get cURL working in Python (pycurl binding
> on windows) I decided to research the other 42 (coincidence.. I think not)
> language bindings.

Thanks for your research and details on the bindings situation!

I understand where you're coming from and I can feel the pain you've
experienced when trying to get this working. I realize it is frustrating.

Let me stress that you had problems with pycurl on Windows. curl is a command
line tool and most likely works perfectly for you on Windows.

pycurl is a separate project from ours and one that severly lacks contributors
and thus isn't updating very much. A common open source problem.

Windows in general is a problem with many open source projects. This is
because lots of users run Windows and want software on their platform, but a
very small amount of the active contributors actually run or use Windows. That
often makes a very skewed ballance. I see this happen in virtually every open
source project I'm involved in.

In the cURL project we've taken the approach to not host and develop the
bindings ourselves but to rely on people who actually know the languages and
who actually want the bindings to do and maintain them. Of course this will
then make them all different and it will make various bindings come and go and
some to be updated and some to be lagging behind etc.

I believe our responsibility is to provide a library that makes it easy to
"bind". We should provide accurate documentation and detailed information
about how things work and what works with which versions. It is also important
to maintain ABI compatibility as much as possible so that older code can work
with newer libs.

We ship new releases roughly every 2 months. We cannot expect that bindings
are updated as frequently.

> The list is below. (Yes I probably made mistakes in places - its a lot of
> bindings). Many of them are suprisingly (to me) out of date. Perhaps a
> concerted effort to help them update would be a "good thing" to do. Authors
> in here: https://github.com/bagder/curl/blob/master/docs/BINDINGS

That list was last updated for more than two years ago, which makes me believe
that lots of the information is old/wrong by now.

> I'd humbly like to suggest re-stacking the current bindings list into two
> lists. Current - and not current.

That's certainly one way to somehow "rate" entries in that list. I'm however
how sure exactly what good it will bring nor how we would make sure to keep
that additional info current when we can't even keep the list up-to-date
without that additional info... I suspect such a separation will only lead to
an even less accurate list over time.

Also, for many users it might be less relevant how "current" the bindings are
but instead be more important how good they work on their operating system and
in their environment. If we take pycurl as an example, that is a widely used
binding that works really well for a large amount of users - but it isn't
current and it apparently doesn't work for you.

> Incidentally the GTK bindings were incorrectly linked. I found them here:
> http://curl.askapache.com/c/curlgtk.html (2008) (weird partial mirror)

The domain/site of the GTK binding seems to have vanished. The link above
links to our gtk-using libcurl example. That's not the same thing.

I would like to come up with a system that scales and survives over time
better than just a list in a text file that is doomed to always be out of
date. I just don't know what that system is...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html