I'm not opposed, but FriendlyName is optional in the spec and the name is required.

One benefit would be making configurations a bit more readable by referencing the FriendlyName. On the other hand, since FriendlyName is optional, depending on it being there could increase the chance of problems.

I'm leaving this open in case someone else wants to comment for or against.

@warncke I'm not against this either, but even if the option is set, there should be logic to fallback to Name in the case that FriendlyName doesn't exist.

@cjbarth There is logic to fallback to "name" if FriendlyName does not exist: 50024ff#diff-41fc97a3e28a2b6f8b5ec3bdae6130d5R1034

But that seems that could lead to confusion there the resulting profile names are a mix of the "Friendly" and "Non-friendly" names.

What if we add a "friendly" key to the profile returned and make the "friendly" names sub fields of that? It would be up to the end user to default to the non-friendly names if they want to do that.

Ah yes @markstos , I must have missed that due to the wrap. Sorry. But I do agree that we could have implementer confusion if we mix them in the library. It does make more sense to have multiple keys and let the implementer sort it out.

I'm rejecting this because as proposed the result can be a mix of "friendly" and non-friendly names based on the incoming data which can sew confusion in an already complex library.

Friendly names are appealing but because they are optional they can lead to complications.