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
conversion).
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 option net
).
++++
This cannot be done in a sane manner though as it would render future versions
entirely backwards incompatible.Renaming
config interface
toconfig network
makes sense and can be
implemented easily. However we would still need to treatconfig interface
as
synonym for it in the forseeable future in order to retain compatibility,
which means that we cannot reuseinterface
for something else.So changing
config interface
toconfig network
would be possible assuming
thatconfig device
remainsconfig device
(or is renamed to something other
thaninterface
).At the same time, the
wifi-iface
section type in /e/c/network should be
changed towifi-network
in 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:
DSAdevice
DSAinterface
DSAnetwork
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.