gns3 architecture design failure vis a vis gns3_gui.ini

[josephmhiggins]

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.

[josephmhiggins]

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