Could version 7.25 mark the moment of the most radical enforcement of configuration attribute compliance?
From what little I’ve gathered so far about the MikroTik landscape—specifically the relationship between RouterOS and WinBox—my understanding is as follows:
- WinBox retrieves a data model from the RouterOS instance it connects to; based on this model, it establishes preliminary validation rules enforced by the graphical interface.
- Over the years, hundreds (perhaps thousands) of exceptions to this method have been created and hard-coded somewhere within this ecosystem—most likely inside WinBox itself.
- P.S.: If these assumptions are incorrect, please help me understand how it actually works—ideally by pointing to public documentation on the subject.
So...
When you combine the fact that version 7.25 now mandates WinBox version 4.3 (or higher) for access...
With the message from @prawira in the WinBox 4.4 thread—where he described how WinBox 4 prevented him from entering a range attribute with positions in reverse order...
I found myself thinking:
Given that they are adopting a stricter methodology and enforcing a minimum WinBox version...
Wouldn't this be the perfect opportunity to clean up all those hard-coded if statements [2] and ensure that every configuration input method strictly adheres to the exact same attribute validation data model contained within RouterOS? Essentially clearing out the clutter and hard-coded exceptions...
Of course, there is a risk of touching a sore spot.
"Semi-incorrect" configurations—which users have been copying and pasting for years and which have worked fine all this time—might stop being accepted and instead trigger error alerts.
But I believe that by getting rid of all those hardcoded conditions, both RouterOS and Winbox4 itself will tend to become leaner—while also gaining overall consistency across all configuration input methods.