wkitty42 wrote in Sun Aug 13, 2017 7:20 pm:FWIW: i'm working on converting the cockpit-view mod to the --addon format... i'm testing it as we speak
as I mentioned previously, I believe it is a good idea to coordinate such changes with Torsten, especially in order to work out useful enhancements to the underlying addon "framework", so that we can identify overlapping functionality and instead of replicating such features per-addon, we could move certain functions to the addon.nas file itself.
For instance, I mentioned previously, that it would probably make sense to introduce <name>, <version> and <authors> tags at the config.xml level, analogous to how -set.xml files have been structured for years - not just for the sake of consistency, but also to prepare addons for potentially being deployed/updated and managed using the still evolving catalog/package manager backends.
Speaking in general, $FG_ROOT/Nasal has pretty much become a "dump space" over the years, pretty much after mfranz's "departure", whereas it used to be primarily about "library" code primariyl - thus, helping cleaning up $FG_ROOT/Nasal to incrementally move optional/non-key functionality out of $FG_ROOT/Nasal would seem like a good idea - especially for people wanting to see less Nasal code running in the main loop - for the time being, many modules are loaded uncondtionally, despite really being optional.
Then again, it would probably make sense to consider introducing something along the lines of $FG_ROOT/Addons or rather $FG_HOME/Addons at some point, to ship/install pre-included addons, that are packaged during the release process, without end-users having to install those manually.
Doing so would be a great way to reduce the number of Nasal modules that are currently loaded without being required, and only load those on an opt-in basis.
Anyway, if people are envisioning their addons to be potentially managed/updated and installed/removed using FlightGear itself, it definitely makes sense to introduce and use meta-information in the form of <version> attributes, not just per addon, but also for the addon API itself. Otherwise, it will be next to impossible to make breaking changes in the future, which would complicate any efforts to extend the framework over time.
So, if -based on your current porting effort, you should have anything to add to the wiki article, please do feel invited to do so.