Jesus Cea wrote:
On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
Jesus Cea <jcea <at> jcea.es> writes:
4. Modify client libraries to accept a new optional socket-like object as an optional parameter. This would allow things like transparent compression or encryption, or to replace the socket connection by anything else (read/write to shared memory or database, for example). This could be useful too.
I have been thinking about this for years. Do you actually think this could be formally proposed?.
This strikes me as the best way forward (albeit far from easy to do): 1. Existing code which doesn't use the new arguments should be unaffected. 2. No changes to low level socket code, so no chance of unintended side effects on library behaviour 3. Solves a broad class of problems (i.e. allows all sorts of tunnelling and various socket options) rather than just this one problem. 4. Allows easier library testing with "mock" socket objects. The problem actually reminds me of Spolsky's Law of Leaky Abstractions essay. If the abstraction layer is going to leak anyway (and they always do), it's best to give the developer access to all of the tools they need to plug the hole. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------