For Architects - Plugins
The following explains some “technical background” of the development of Sky Dolly. It may also be interesting for those who want to know how to tweak the installation for minimal installation size.
Plugin Architecture
Since Sky Dolly v0.12 also the so-called modules are implemented as plugins. Modules provide the major functionality, such as the logbook, the formation recording / flying and newly also the locations.
A “plugin” is a set of functionality that is completely optional at runtime: it extends the base functionality of the given application if present, but otherwise can be completely removed. Where “present” means that the plugin (typically a “dynamically loaded library”, DLL) is located in some well-known location, a directly typically called the “plugin directory” (or directories).
Technically speaking: the plugin implements some well-defined interface - the “contract” between the application and the plugin, so to speak. The contract defines the expected input and output (result or functional behaviour in general).
One such example is the simple export interface of Sky Dolly, which defines exactly one method to fullfil (implement) for each export plugin.
Once a plugin faithfully implements such an interface it can be loaded at any time during runtime - on demand. As opposed at application load time, where a missing DLL typically prevents the application from loading.
Efficient Memory Management
This implies that - since a plugin is completely optional - that it can also be unloaded after use. And this is exactly what Sky Dolly does: not only are import / export plugins unloaded after use, but now (since Sky Dolly v0.12) also the modules.
Especially in the “normal (non-minimised)” UI mode this leads to another measurable reduction in RAM usage (*):
Whereas the previous v0.11 was still using 98% of RAM when launched in “normal UI” mode (compared with the reference v0.10 with 100% relative RAM usage) the current v0.12 is now only using 77% of RAM (again, relative to the reference v0.10 usage). Or almost a quarter less than the v0.10!
The same figures in absolute numbers:
(*) All measurements were made with an empty logbook, in order to make them better comparable between each other (which leads to even slightly better numbers than posted in a previous post above). The RAM usage was simply measured with the Windows task manager multiple times.
Architectural Benefits
Not only can a plugin architecture lead to less RAM usage (when plugins are unloaded after use, that is), but is also leads to a better software design (“architecture”). The functional parts are strictly hierarchical - and hierarchy is good when it comes to software design, as “mutual dependencies” (“A calls B and B calls A”) are prevented.
In fact, especially with a plugin architecture such “mutual dependencies” are “physically impossible”: an application would not even “link” when an attempt from the main application was made to directly call a function implemented in a plugin (or generally speaking: to call “higher level functionality” from a lower level).
Or simply put: “Spaghetti code” is simply not possible.
Tweaking the installation
As plugins are optional by definition one can also remove them from the corresponding plugin directories. Don’t need that import plugin? Delete it! No need for the new location module? Remove it!
Not only does this regain some storage space, but may also improve the user experience itself (by not providing functionality in the user interface that is never needed).
Sky Dolly stores its own plugins in a subdirectory called Plugins. The plugins are further organised into the following subdirectories therein:
- Connect - yes, even the connection with the flight simulator (currently: MSFS) is implemented as a plugin
- Export - export plugins (CSV, GPX, IGC, JSON, KML)
- Import - import plugins (CSV, GPX, IGC, KML)
- Module - the modules which provide the major functionality (logbook, formation, location)
Unless the connect plugin is removed Sky Dolly pretty much remains functional (however Sky Dolly even launches - with much reduced functionality - without a connect plugin ;))
Community
No software architecture would be worth anything if the actual functionality wouldn’t let you do what you are trying to achieve, in an efficient manner! So the overall goal of Sky Dolly is still to simply provide the best functionality with the biggest usability (ease of use, “least amount of clicks”).
I do understand that especially the formation module is not exactly intuitive enough just yet (respectively people have different expectations, like that “AI aircraft automatically follow their user aircraft”). I am also still working (eventually ;)) on the online manual, with both a “reference manual” and “goal-based tutorials” (“How do I get XYZ done!”).
However feedback such as the following “tutorial video” is very encouraging and rewarding. The video gives a quick overview about Sky Dolly’s functionality, including the new location module:
The video is shared with kind permission from the author, Pilot Studd. Go check out his other videos, too.