In coda_network I've got a mini proxy using ForkingMixin to do a process per download bypassing a lot of GIL based multithreading pain. I needed some more multi processing support for some shared state and possibly locking. So I started trying to do a MultiprocessingMixIn for the SocketServer/TCPServer/BaseHTTPServer. I thought "this is easy just rip off the threading one since they share the same interface". That worked really well for general use but when I started putting the system under severe load the process cleanup started going wonky.

Eventually I think I got it working using this code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

class MultiprocessingMixIn:
    """Mix-in class to handle each request in a new process."""
 
    # Decides how process will act upon termination of the
    # main process
    daemon_processes = False
 
    def process_request_process(self, request, client_address):
        """
        Same as in BaseServer but as a thread.
        In addition, exception handling is done here.
        """
        try:
            # Actually do the request
            self.finish_request(request, client_address)
        except:
            # XXX: will this work with multiprocessing correctly?
            self.handle_error(request, client_address)
        finally:
            # Close the socket request
            self.close_request(request)
 
    def process_request(self, request, client_address):
        """Start a new thread to process the request."""
        t = multiprocessing.Process(target = self.process_request_process,
                             args=(request, client_address))
        if self.daemon_processes:
            t.daemon = True
        t.start()
        # Now we close the parent request socket because the child process
        # is now responsible for it
        self.close_request(request)

The important bit is closing the request in the parent after the child process has started since it takes responsibility for it then.

1
2
3
4
5

class ProxyServer(MultiprocessingMixIn, BaseHTTPServer.HTTPServer):
    pass
 
proxy = ProxyServer(address, HttpResponder)
proxy.serve_forever()

I've probably missed a couple of bits (like making sure the handle_error does what is expected) but this is at least a good starting point....

So what changes have gone in?
* A skeletal mock proxy server that can fake HTTP and HTTPS requests. This will perform the basis of unit testing.
* Fix a bit where TCP keepalive failed to happen over HTTPS.
* Implemented MD5-sess digest authentication which seems to be what IIS Windows servers use.
* Added an authentication handler for OAuth.

The authentication handler for OAuth was the most work. Essentially I had to extract the OAuth logic from oauth2 and remove all the close coupling with httplib. This then means you can have an OAuth handler in the urllib2 world of Python and do it through proxies and the suchlike. Your server does need to return a 401 rather than the ones I have seen that get a 500 internal server error when the request is made without authorisation.

To get it working I cheated and reused username and password because they have little meaning in the OAuth world. So you end up with something like this (you can skip the token part if you don't have it yet):

password_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
password_mgr.add_password(None,
'http://oauthprotected.com',
KeySecret('consumer_key', 'consumer_secret'),
KeySecret('token', 'token_secret'),
)
auth_handler = oauth_auth.HTTPOauthAuthHandler(password_mgr)


It is all done entirely in HTTP headers and there is no option for GET or POST parameters.

First up I started with a simple Optimus Prime to pass the time.

Then Optimus Prime needed someone to fight, so Megatron popped in.

But Megatron was upgraded into the insane killing machine of Galvatron.

Hot Rod (for some reason channelling David Bowie) is needed to keep Galvatron in check.

The chaos bringer Unicron keeps a close eye on testing in planet form.

A tough looking Iron Man decided to get in on the act.

Then we go back to a slightly better rendered Optimus Prime.

A childhood creation of an old friend is Thunder Supreme - the city robot.

Robocop helps organise a Python Code Dojo.

Judge Dredd pronounces sentence on Twisted.

Death's Head slightly sketchy, yes?

Death's Head II was fighting at keeping Windows at bay. But I fear he may not be powerful enough.

I also did not only end up sketching such luminaries as Optimus Prime, Megatron, Robocop, Death's Head (1 and 2), and Judge Dredd, I actually took some notes as well(!)

This write up has taken me a few weeks since my iPhone4 died completely then my Macbook Pro decided to contract the nvidia graphics chip of death.

Russel Winder - The Multicore Revolution
The everything you've held true all this time is going to change speech. Russel was thoroughly entertaining as usual especially with the sidetrack into physics. He stepped in at the last minute for someone dropping out going to OSCON or something, but if they hadn't said noone would have known or complained.

Idiomatic Python/Python Tips and Tricks
This was the talk of the conference (there was a second part later I unfortunately missed because it overran). Basically everyone in the audience no matter how expert they were in Python will have learnt something. It rattled through at great pace. Stuff I learnt included:
Copying a sequence c = s[:]
Delete a sequence s[:] = [] or del s[:]
Iterating an array using enumerate() means you get a pair of index, value
Iterating multiple sequences with zip() means you keep the arrays in lockstep
You can do a for -> else

Python Development Process
I simply had to go to this because now I am thinking about the process to merge my changes I have made in coda_network back upstream since they seem to be working quite nicely now.

The branches are:
3.2 - branches/py3k
3.1 - release31-maint
2.7 - release27-maint
2.6 - release26-maint

To do an update and compile of the source do ./configure && make
Or you can do a debug version by ./configure --with-pydebug && make
And you only need make if the C files have changed.

Writing tests is extremely important, so write them check they fail, fix the problem and re-run the tests to make them work! You should run your tests with Lib/Test/regrtest.py

To run all tests do ./python -m test.regrtest -uall and to do a specific test replace uall with the test name.

Apparently there is a maintainers file under Misc/maintainers.rst which should be very useful.

How Import Works
I went to this because it can never hurt to know what is going on int he background. It covered some of the new functionality including relative imports which you can get at on older versions by doing "from __future__ import absolute_import" then you can do funky stuff like "from ..spam import flying_circus".

So the process of doing import:

• Resolve the name.
• Find the module, it is possible to create custom finders that can drag your package from anywhere like the internet.
• Then do a loader.load_module(fullname) and you've got it.

They are putting in a __pycache__ where all the .pyc files go so you can use multiple interpreters without conflicting .pyc files and also they don't get left around on your hard drive because they are all in one place. It helps prevent having stale .pyc files that can be accidentally imported.

Cross Platform SIG
This was an impromptu talk because there were quite a few drop-outs for talks. I decided to go because I feel Windows stalking me at every turn and I can only run away for so long.

The most interesting part was reimplementing UNIX commands in Python for some self contained non-administrator helpful commands.

Also mentioned was Sphinx for generated Python documentation and Homebrew for Mac OSX to get a slightly better dev environment.

Monstrum - Python HTTP testing in Python 3
Seems to be testing by using HTTP headers.

Porting Python 2 to 3
One thing I wrote on my notepad was "Hiding to nothing". I seem to remember thinking it requires a lot of effort and the ideal solution could conceivably be the most work which is a codebase that works in 2 and 3.

MUDDLE - A Build System
Muddle is a build system for building embedded systems written in Python. Considering my day job I could not miss out on this one since it is very relevant. It supports lots of VCS, and build systems (make, linux kernel, apt-get, initscript, version files, debian files). Basically, I need to find the time to really experiment with this and attempt to build a system.

KBUS - A simple messaging system
This is a messaging system using a Linux kernel module. It is modelled on a socket model which is really easy to wrap your head around. The testing is all done in Python which makes it really powerful to use. It is definitely worth considering over dbus as that is really incredibly painful. I know some uses for this already myself after the pain of dbus and dbus-python.

Open Standards - Democratising The Web
Bruce Lawson from Opera had the keynote about open standards on the web. He gave this interesting link about accessibility. He also mentioned the media queries for CSS to layout your content from different resolution screens and physically shaped devices. Also he mentioned html5patch for cross browser html5.

A Case For Accessibility
This is a subject close to my heart so there was no way I was going to miss this. They designed Mediacore with accessibility in mind.

The W3C says 10% population in most countries has a disability and the average age of the population is increasing such that the rate will get higher. They found actually seeing people with disabilities attempting to use the web through screenreaders and the suchlike made them see how hostile the web is (I am looking at you Tescos after your redesign, but that is a whole other article).

Things you should be thinking about are:
Order of menu items and in fact number of menu items.
Alt text for images - people still don't do this!
Form labels
Tab order
Headlines and paragraphs are semantic and help
Hiding things right. display:none does not necessarily work with screen readers.

Some accessibility guidelines are available here.

And something even closer to my heart, reduce or eliminate Adobe Flash completely.

It is also easy to partner with a visual disability centre, like for instance the RNIB or Sense. There is also some Non Visual Accessibility web certification.

HTML5: the good, the bad and the quite interesting
And this talk was really quite interesting. Just talking about the new things that are getting added to the HTML standard (the title is really honestly for marketing).

You've got new things like a header element that can go anywhere, and a nav element to contain say a group of links. You can tag something article which is a discrete piece of content. There is now a time element to unambiguously mark something as a time and date.

Interestingly (although Opera is the only browser implementing it right now) is form validation so you can have HTML smart forms which flag up to the user when something needs attention.

First Round Of Lightning Talks
There was the face tracking robot called Hedroid that delighted the audience. We had a talk about how the mobile interface for the schedule was knocked up in a pub and deployed in about an hour. There was the pyweek game development challenge. The online pygame book. And a few more.

Python On Windows
Just to see how Python is getting on in the world of Windows and what real world stuff people are doing with it. CPython from the standard installer seems to work well for most people and there are a few useful packages like active_directory, wmi, and pywin32.

Python In The Browser
This is web programming using Silverlight + ironPython. It's an interesting thing to see and looks like it could make Windows development more palatable. There is a really good demo here for the Python tutorial code executed in the browser. The useful addresses are gestalt.ironpython.net/dlr_runtime.js to get python in the browser using Gestalt and silverlight.codeplex.com for the Silverlight Toolkit.

Like I say I see Windows stalking me in dark alleys....

The State Of Python
Another day, another keynote. Interesting bits from the talk included Skulpt which is an implementation of Python in Javascript. Also there was Berp which is Python 3 in Haskell that compiles down to Haskell. Also a mention was made of distribute and pip which should help with the minefield of deployment.

Organise a Python Dojo
An entertaining talk about how the London Coding Dojos started with a strict adherence to the rules and how they evolved into what they are now. They have things like multi-week projects divided into small units (like a text adventure game). I think what I really took away is start with the default arrangement then find what works with the type of people.

Twistify Your Library
And
Deferred Gratification
I think I sat in these because I lacked the ability to stand up and it was nice and air conditioned. What I really learnt is Twisted deserves its name and it is implemented in completely the wrong language. My sketch involved Judge Dredd declaring "Guilty! The sentence is death!"

The Guardian API One Year On
This was about the kind of things the Guardian API is now capable of and how it is the antithesis of the newly implemented Murdoch Paywall. The first example was an online version of the paper which can be viewed here and there was the zeitgeist example. Basically there are three levels, keyless for simple access, approved to get at the actual data, and bespoke for full access with no ads. They have also opened up a large variety of data in the Guardian Datablog.

gevent library
This is a library for large multithreaded programs. It is a lot more sensible than Twisted and fits into the Python semantics a lot better. It still needs a lot of work for various other python features like subprocesses.

More Lightning Talks
I did a talk about coda_network and fixing up httplib and urllib2.

There was a quick one about __main__.py which was really interesting because you can do all kinds of packaging like adding all the files to a ZIP and making it work. Creating a __main__.py means you can execute a Python library which is really cool.

There was a talk that mentioned all kinds of hackery you can do with the with statement. One library is withhacks.

There was a really cool demo of pdb++ a new funky python debugger. I think the repository is here.

I've skipped some bits of Europython because I simply had Python overload and I am sure important stuff got pushed out of my brain.

I was not sure if the tech was there to even show the keyboards automatically when an input field was selected. GTK are well ahead of the game on this with their IMContext base class to encapsulate input mainly for complex languages or disability accessibility, but a good side-effect is the ability to hook in an on-screen keyboard when a text input is focused. In that case the on-screen keyboard needs to know about GTK in order to know when to show.

I tested all these on a VM that has now run out of hard disk space thanks to having to compile lots of stuff. Most of the keyboards I completely failed to make automatically appear on the screen when a text input was selected, it was either me or them....

So in no particular order....

Matchbox Keyboard
Some people are using this actively. It requires hacking to be able to toggle the display of it which makes it pretty much a no-go as it would always be on top of the screen. The GUI looks all right though. Some good info here.

xvkbd
The venerable old man of the line up. It's been around the block and does exactly what it says on the tin. It has lots of good features and hacks (like making it appear for login windows). As far as I could see I couldn't hook it up to the IMContext but I could be missing something.

Gnome On-Screen Keyboard
The oldest GTK based one and seems to be showing its age thanks to the UI.

onboard
This is the Ubuntu one. I couldn't get it to automatically appear on focus. It looks OK, but seems to be lacking some features. At least it is easily hackable in Python. Some more interesting information is here.

Florence
This is the most recommended one and it is pretty good. The main pain was I had to compile it as their were no packages for it.

fvkbd
This looks fairly promising as it is very skinnable on configurable. Unfortunately I could not work out how to hide or autohide the keyboard. Also this had no packages and requires compiling. This provides the basis for the OLPC virtual keyboard test and also the Meego/Maemo virtual keyboard.

Caribou
This is the virtual keyboard testbed for Gnome 3.0. It is written in Python and needs packaging so I had to compile it. This was the one that got closest to what I want because it worked. It shows a small keyboard by the input with current focus. In my VM I had to disable the Clutter code for whizzy animations before getting it to work.

I've probably missed some but there are only so many not quite ready applications you can test before going completely and utterly bonkers.

Another thing I discovered was Google Chromium's addressbar is accessibility implemented, but none of the content in webpages is. Firefox on the other hand and anything WebkitGTK based (like Epiphany) all work properly with their accessibility. Part of the Chrome problem is the multiprocess rendering and that they have not prioritised accessibility according the bug reports I have read.

First up the nvidia ION platform it is using is the MCP79 (revision b1). They are all much the same when it comes to ION motherboards with the revisions.

lspci output:

00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b3)
00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
00:0b.0 IDE interface: nVidia Corporation MCP79 SATA Controller (rev b1)
00:10.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
02:00.0 VGA compatible controller: nVidia Corporation Device 0876 (rev b1)
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8172 (rev 10)


The mini PCIe networking card is a Realtek 8172. Ubuntu details are here and driver install instructions are here for older kernels. I found the drivers very problematic, and according to the discussions out there on the Internet many other people struggle to get it working well on Linux.

You'll also notice there are no ethernet controllers listed.

And now stuff from dmesg....

A normal looking Atom chip.

CPU0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz stepping 02

And I assume hyperthreading is enabled:

CPU1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz stepping 02

Bluetooth is pretty standard:

Bluetooth: Generic Bluetooth USB driver ver 0.5

About 128Mb is allocated for graphics from the 1Gb total:

Memory: 888772k

There is a USB hub with 6 ports somewhere:

hub 4-0:1.0: 6 ports detected

The touch controller:

input: eGalax Inc. USB TouchController as /devices/pci0000:00/0000:00:06.0/usb4/4-1/4-1:1.0/input/input3

The driver for the touchscreen is here.

There is a keyboard somewhere maybe it is used for something internally:

input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:04.1/usb1/1-1/1-1.2/1-1.2:1.0/input/input4


I'm still trying to work out the ambient light sensor and rotation sensor (which allegedly us ACPI through a hacked kernel that has not been GPL released yet).

Why was I so keen to get hold of one? It is essentially an nVidia ION in a tablet. At Camvine the main hardware is based on this platform, so I thought it would be a great toy to play with and get our software working on it. I can say my gut feeling was right and I had it going quickly.

No pictures for this one as they are all over the Internet. But check out great internal photos here.

And on to the review....

HARDWARE
I'll start with the hardware. It's not badly done, with a nice sturdy engineered body. The quality of finish does surpass what I thought it might be. What we have is nVidia ION netbook internals crammed into a slim tablet chassis.

The Display
The screen size is just wrong, I know why they went for 16:9 (with a very respectable 1360x768 720p resolution) but it just doesn't work. When you are in portrait the top of the screen is way too far away from you. The screen is really configured for movies rather than web browsing with that shape and resolution. Ideally for a tablet you do want something closer to 4:3 and each edge being a minimum 1024 (I'll come onto why in the software section). The viewing angle on the screen is good in one direction but then the other it is literally useless and you end up tilting it to see the content.

Heat
The tablet does get very hot. It has a fan internally which you can hear quite clearly when you hold it up to your ear. That is good, but the thing that gets really hot on the ION is the video chipset (I've seen it going at 70ºC). The heat seems to be at its greatest somewhere around the battery pack area which is odd since it is the other side to the processor.

Power Button
Either my fingers are too big or the power button is just not very good. It is quite good as it is orange when charging and white light when on, but it is recessed too far and seems terribly unresponsive.

Ambient light sensor
Great to have one, but unfortunately it is positioned more or less where you place your left hand when you are operating in landscape.

Weight
It is a bit more weighty than it needs to be but I put that down to the screen size. With a smaller, better screen it would have been much more of an impulse device to use.

Logo
The logo on the case appears when the JooJoo is switched on which is a real nice touch. Also it illuminates the right one depending on the orientation you are currently in.

Webcam
It has a webcam but I have not seen that it works - maybe it is for future software releases.

Overall
I simultaneously dislike and like the hardware (from an external point of view). For the internals some corners have been cut. The niggles take away from the final finish, so with things like ambient sensor positioning, power button, and screen physical dimensions fixed it would be a lot better.

SOFTWARE
For all of the hardware it is the software that will make or break the platform. The software is basically a web browser with a web based start page showing bookmarks, with compiz to switch between windows.

Boot Time
It is fairly quick to boot, but now lots of things boot quickly. It mainly suspends when you "power off" and then restart. This is great for speed but unfortunately the software can get upset so you need to reset hard in order to get a working system.

Main Menu
The main menu at the top I still haven't quite worked out how you are supposed to bring it up. Sometimes it is a tap at the top and sometimes a one finger swipe near the top. Sometimes it is the top left only as well.

Wifi
It seems it can only remember the last wifi network you were connected to so you have to type in the password again and again when you change locations. For a portable internet connected device that is pretty poor.

Scrolling
The JooJoo is "multitouch" for differing values of multitouch. Essentially the only thing I have found multitouch is that webpages scroll by using two fingers (like the Apple touchpad). There is no other functionality I have found like rotate or pinch n zoom. The really annoying thing is that the main webpage that you start from uses one finger to scroll (due to the HTML implementation I am guessing) so once you are used to two-finger scrolling going back to the main page is really painful.

Web Browser
According to some hackery on the JooJoo forum the browser is actually Google Chrome. It is surprising it has some performance deficiencies in scrolling and browsing. The browser supports Flash as well which may please some people (my intense aversion to it does not endear me to it).

Multitasking
Because all webpages you have open are essentially live, you can end up with a Flash video playing int he background sapping CPU without even realising because it does not suspend the background processes.

Compiz
You can switch the active web browser window using a compiz based switcher. It hasn't been nicely user tested as you can end up scrolling off the left or right and struggling to get an active window. To throw away a page simply chuck it off the top which is a nice gesture.

Rotation and Orientation
Rotation is obviously done using xrandr. This means no nice animation when changing orientation and you get the horrible destruction/creation of the framebuffer. Also the orientation seems to only have only two active edges because otherwise the illuminated logos would be upside down. This makes it inconvenient.

GTK
It obviously has some GTK in the background (for Chrome), but I have seen GTK error dialog pop up momentarily whilst whizzing around the compiz 3D bit. It looked very odd. Also in the Chrome browser it is obvious there is no GTK theme because you have the default (and off-putting) grey standard widgets for combos and the suchlike.

Webpages and Scaling and Zooming
As I mentioned earlier there is no pinch and zoom and no way to scale webpages. This is really important because of the resolution of the device. One direction it is 768 pixels, so most webpages are designed with a minimum 1024 width and this means that you have to scroll horizontally to see a whole webpage. There are two solutions - either scale a webpage (which is really easy in WebKit - even I have managed it for CODA), or supply a screen with a minimum 1024 in both directions (1280x1024 is still a great resolution).

Security
Okay, I log into all of these webpages and then switch off the device. Someone else switches it on and they can just go straight into those webpages because it simply remembers the credentials. This is a wide gaping security hole and brings me onto the next thing.

Users
It is a single user device. I am pretty sure there is no particular "user" on this linux system, this means it is right pain for more than one person to check their gmail on this device.

Overall
The software is OK for a toy, but not to be used beyond an internal engineering practice. I was pretty annoyed by it after five minutes, so it is time to nuke it.

HACKY HACKETY HACK HACK
So the real reason I got it was to hack my own OS onto it and to play around writing apps for it.

For a stand I decided to order a plate display stand which should work a treat and you can get two for a fiver(!) Also I have ordered a 2Gb PC3-8500 204 pin DIMM for £25 to up the memory. This should make it even nicer to hack on.

The SSD storage is the biggest debacle though, it is a mini-PCIe mSATA with some flipped pins which makes it impossible to find a replacement. People have been trying for while now. However, what I have ordered is a SD card to mini-PCIe adapter so I should be able to shoe-horn in some storage.

The wifi is also horrific, it is a Realtek card and as anyone who has tried to get these working on Linux solidly can attest they are cheap and nasty. I can't get it to work even when compiling the module under a 2.6.31 kernel. I might find another half height mini-PCIe wireless card to replace it with, Atheros has been quite good (and maybe find a wireless N).

The best bit is the screen and touchscreen is mounted upside down so all firmware images and media are stored upside down. Pointless attempt to avert hacking....

IS IT THE END YET?
So the JooJoo is good and bad, I couldn't recommend it to "normal" users, but it is a real interesting hacking platform. If some of the tablet OSes come out this year they could give it a whole new lease of life. Hardware wise it is nearly there, but needs more work (and battery life). The software is a long way from being first useful, and then good which is unfortunate.

Mainly these involved using an NTLM proxy and attempting to tunnel a socket through it. This makes sense of the proxy case where you are trying to daisy-chain sockets together. This was really an issue with keep-alive proxies where the Request object was not resetting some cached state that would only ever work once.

The main feature now though is I have added mini_proxy.py. A multiprocess proxy server using all my code changes. Only GET, POST and CONNECT are implemented, but that should be sufficient for most tests. This mini proxy can then speak to upstream proxies of no authentication types, as well as basic. digest, and NTLM.

The readme on the github page has been updated with example commandlines for the proxy and I have tested it against all kinds of proxies. Because of all the other work put into httplib and urllib2 the proxy itself is actually only 200 lines. I've got no idea how efficient it is, but it should work fine.

So what am I planning to do next for coda_network? To be honest it is functionally complete from my requirements but there are some less glamorous things that need doing.

• Finish writing up the unit test suite for proxies, downloads and requests.
• Add some more example scripts for downloading and the suchlike.
• Add an example mini_proxy that is half written right now that provides a Python based local proxy that can connect to any of the supported parent proxies.
• Fix any bugs I find and from any feedback.
• Try to egage the Python community to get these fixes or something similar pushed upstream.
• And when I feel really brave - go have a look at Python 3.

Originally the networking code at Camvine was based on httplib a very long time ago, then Curl was used (pycurl specifically with changes pushed upstream), but now I have been using normal Python 2.6 standard library functions which is much nicer. The default one distributed was not sufficient so I had to make some fixes through deriving classes and monkeypatching. That is a very basic history of the coda_network package's origins.

I've based these changes on the Python 2.6 maintenance branch so it should in theory work with all versions of 2.6 Python (and I suppose possibly the 2.7 release). I did maintain my changes as patched derived classes, but I decided to integrate the changes into urllib2 and httplib directly in an attempt to eventually get these changes or something similar to them upstream.

Camvine have allowed me to publish the source code for all of these fixes so I am putting them on github with my often strange commit comments. I'll get on to the functionality and fixes that I provide in a moment. This all stemmed from attempting to fix tunnelling HTTPS through proxies and then having to fix it for NTLM.

In the repository there are the new httplib/urllib2 files which can be dropped in. They have been made part of a coda_network package along with a few other helper files.  Below is the readme in the github repository.

coda_network

Author: Garry Bodsworth Website: http://www.programmerslog.com

Thanks to Camvine http://www.camvine.com for allowing the source to be published.

The changes are based on the Python 2.6 maintenance branch so it should in theory work with all versions of 2.6 Python (and I suppose possibly the 2.7 release). The changes were maintained as patched derived classes, but now they are integrated into urllib2 and httplib directly in an attempt to eventually get these changes or something similar to them upstream.

In the repository there are the new httplib/urllib2 files which can be dropped in. They have been made part of a coda_network package along with a few other helper files.