david raistrick <drais@icantclick.org> writes:
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all.
So the software engineer should now -also- be responsible for, and capable of, recreating both the network as well as 3rd party systems that he/she has to code against?
I am not claiming that every engineer in a big project should have all knowledge necessary to complete the project, or have the responsibility for every task in the project. But defining and configuring a suitable test environment is an absolute requirement for any software project. So *someone* in a network software development project will need to know how to set up networking for the testing.
again focusing on just our last title release - 20+ 3rd party interfaces run by 6 different companies. Is the software engineer really responsible for faking things like xbox live, PSN, facebook, twitter, google, etc on a test network?
If your application interface with those services and you expect those parts of the application to work, then I'd say so, yes. There may be occasional exceptions from this rule, but most of the time you'll find that any untested parts of an application does not work. Now I'd guess that most of those services also offer a test environment. You will of course primarily use that. The claim wrt IPv6 was that it was too difficult to use existing test enviroments. The degree of real world simulation you need for testing will of course vary. It's not like a hobbyist Android app developer must set up his own cellular network. Running the app in an emulator is likely enough for most uses, including IPv6 testing. This discussion seem to go off into the wild, so I am not sure there is any point continuing it. But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software. That's simply not possible. If it fails on IPv6 then it is guaranteed to fail on IPv4 as well, only less obvious ond therefore more dangerous. The claim that missing IPv6 support in software has anything to do with the lack of native IPv6 internet access is just stupid. You may wonder how anyone could develop a new protocol, or microcode for a new CPU, or a driver for a new hardware device, or anything at all really. You just cannot count on having access to a full scale production environment during software development. You will have to find some way to simulate the missing parts. Native IPv6 internet access has never been a requirement for developing IPv6 aware applications. That was a bad excuse even 10 years ago. Today it is just ridiculous. Bjørn