I'm hoping some contributors to the mailing list read this part of the forum. I don't think it would be good form for me to attempt to join the developers mailing list.
Re: the current discussion around DSA terminology - some excerpts follow:
Well, it would still be less confusing than the state we're currently in.
Anyway, converting "config interface" to "config network" and "config
device" to "config iface" is an option.
I don't like
iface, it is also easily confused with
interface (which - as
explained - still has to be supported in the forseeable future even after the
Apart from that we should try to rid of abbreviations in configuration or at
the very least follow a consistent set of rules (if there'd be a
config iface then networks should be called
This cannot be done in a sane manner though as it would render future versions
entirely backwards incompatible.
config networkmakes sense and can be
implemented easily. However we would still need to treat
synonym for it in the forseeable future in order to retain compatibility,
which means that we cannot reuse
interfacefor something else.
config networkwould be possible assuming
config device(or is renamed to something other
At the same time, the
wifi-ifacesection type in /e/c/network should be
wifi-networkin order to remain consistent.
The problem: "config interface" (and the similar "wifi-iface"). We're switching
the word "interface" (and "iface") that has been used in config files from one
concept to another. This could leave the config files with ambiguous commands.
I suggest that using the same or similar term to mean different things is a recipe for great confusion.
I suggest that any new terminology is flagged by prefixing the term with 'DSA', so we have:
this is unambiguous, and shows that the new terms are connected to the use of DSA, rather than having to guess what interface and iface really mean.
Configuration files could accept both an old (arguably incorrect) term or the new DSA terminology as synonyms without causing confusion.
If a subsequent revision of DSA terminology occurs, it would be simple enough to flag with DSA2device, DSA2interface, DSA2network etc.
At some point, use of the older terminology could be deprecated and one-off configuration translation/rewriting process applied at a system upgrade, if it were felt important enough.