[MERGE][bug 147530] pycurl http implementation peeks under the covers

John Arbash Meinel john at arbash-meinel.com
Mon Oct 1 16:46:10 BST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:

...

> Well, I went that route for the following reasons:
> 
> - looking at http://cool.haxx.se/cvs.cgi/curl/include/curl/curl.h
>   I realized more tweaking was to come (deletion of some error
>   codes notably),

Actually, I see:

In all cases, macros were added to preserve source (and binary)
compatibility with the old names.  These macros are subject to removal
at a future date, but probably not before 2009.

(Part of revision 1.323).

So I would just stick with what we have, because we'll probably stop
using pycurl by 2009.

> 
> - from above, we can't have a unique fully-compliant-with curl.h
>   definition (even with my proposed _get_pycurl_errcode),
> 

Again, because Curl itself ensures compatibility, that isn't really true.


> - it's now a race between curl and when we drop pycurl support ;-)
> 
> - these errors codes should not be used outside of _pycurl.py
>   (the abstraction level just above is HttpTransportBase), and
>   indeed, so far they have been used only there. Why a different
>   file ?

I agree, but having the error codes in a self contained file makes it
easier to grab them. I agree they should be only used locally.

Also, having more defined than we currently use, helps when someone
says: "I got pycurl error 524242, WTF?". We don't have to track it down
nearly as much.

> 
> - keeping them in the same file and defining only those that are
>   used seems to minimize the risks of another regression.

If they were actually changing things in a regressing sort of way, I
would agree. Since they are changing them in a "compatible" manner, I
don't think we have to worry about it. And I would rather have the extra
codes in case there are errors that we don't realize we aren't properly
handling yet. (I'm sure there are still some out there, as we aren't
using all of them.)

> 
> Thoughts ?
> 
>          Vincent
> 

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHARZCJdeBCYSNAAMRApe6AJ4lhP70kAivEq+V9H4TPOu56jb4AQCfXQE8
hhmPS2w0GuJS7vA2lQIJVUc=
=QQ/7
-----END PGP SIGNATURE-----



More information about the bazaar mailing list