gns3 architecture design failure vis a vis gns3_gui.ini #2139
josephmhiggins
started this conversation in
General
Replies: 1 comment
-
The gns3 developers need to reevaluate what, and what not, belongs in gns3_server.ini and gns3_gui.ini (obviously the extensions are different for each operating system). But I see no leg to stand on for the gns3 developers with respect to the architectural design of those "config" files are < gns3 version 3.0 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Per Ean Towne, we will have to wait for gns3 3.0
But...
Per gns3 developers should never implement a change that puts timestamps in gns3 config files #2118
and gns3_gui.ini:
state:
recent_projects:
recent_files:
geometry
I will have to create a wrapper around gns3 so I can backup configuration changes.
recent_projects is not a configuration change
recent_files is not a configuration change
geometry, I do not consider a configuration change
state, I do not consider a configuration change
the datetime the gns3_gui file was save is not a configuration change
This is not a programming design.
I should not have to create a wrapper around the gns3 developers architecture.
My new Start-Gns3.ps1 works great.
My new Start-Gns3.ps1 calls my fixed Backup-Gns3AppData.ps1
My fixed Backup-Gns3AppData.ps1 works great.
I will have to let my Backup-Gns3AppData.ps1 slide a bit while I look over the
properties recent_projects and recent_files.
I do not know what State and Geometry are, but I am not backing up how big my gns3 gui is.
Again, per Ean, I wait for gns3 3.0
I should not be forced to create a wrapper around the gns3 developers -which I am now.
The gns3 developers create wrappers around qemu, npcap, et. al.
I should not be doing this.
I will publish my start-gns3.ps1 and fixed up backup-gns3appdata.ps1 in the gns3 community - soon.
Beta Was this translation helpful? Give feedback.
All reactions