[En-Nut-Discussion] Attempting to fix network config API.

[Harald Kipp]

Hi Thiago,

in general I share your opinion about the current network configuration.

Nut/OS folklore:

In early time we, egnite, had a US customer, who wanted to use Nut/OS.
However, he insisted on DHCP, which wasn't available and had been
"hacked in" somehow within a few days. Too me, it is a major example for
how long such hacks survive. It had been discussed in this list many
times and several cosmetic changes had been applied. But actually
Nut/Net DHCP had been an inflexible piece of crap since it was
introduced. Some Nut/OS examples using this API are even worse. If I
remember correctly, running the FTP server example once may result in a
hard-coded IP address stored in NVRAM. If Ethernuts in our network got
duplicate IP addresses, I typically comment: "Oh, someone ran the FTP
server example on these boards." -- EOF --


On 20.08.2014 04:11, Thiago A. Corrêa wrote:

>     Any suggestion for names? I wouldn't like to append numbers to the
> API names. It would be best if we could reuse the current names (break
> current behavior). Just occurred to me to make it a configure option,
> to select old/new behavior.

There had been several incompatible changes during the last months. At
least most, if not all of them had been unavoidable and can be disabled
by configuration. We, including some of our customers, do have several
applications, which run fine with all versions of Nut/OS 4. But moving
them to version 5 is usually a pain. Due to the lack of a related
document (how to migrate from version 4 to version 5), you need some
knowledge about Nut/OS internals and some time to figure out, why your
app stops working on the latest Nut/OS release.

Adding new incompatibilities just to keep API names would worsen this
situation without need. I also agree: Just adding numbers to existing
API names like NutDhcpIfConfig_3_() is simply ugly.

I'd recommend to create new names. For example, the prefixes
[Nut]NetSetupXxx() seem to be unused. If this new implementation
requires duplicate code, go ahead. Duplicate code is bad, but breaking
existing code is always worse.

Regards,

Harald