Once say Prat has loaded its data to the shared registry, it would use the registry for lookups, and only add to it if you add more mappings. If prat has no stored mappings, it could still use the ones another addon provides. Its better than nothing.
That's where the problem comes. If Prat is using a mapping that another addon is providing, if the user deletes/uninstalls that addon, that mapping is gone and Prat will no longer have any main/alts data.
Hence, a central storing addon is required, and the addon should just come with the library API itself (like MobHealth). I do question whether any wow user is likely to run more than one addon that requires main/alt data. If the answer is very unlikely, then this library should not be made.
Example:
LibBabble-Herbs
It was created, as a localization library for all herbs. Guess how many addons in the world use it? One. Cartographer_Herbalism. The same applies to the ore/gas/fish babble libraries. They were created as libraries for the sake of creating them, although no other addon was likely ever going to use it.
Now you can argue that Gatherer and/or GatherMate could use the same library. But that again defeats the purpose of a shared library - its to SHARE the library so there is less memory usage, but no sane user would run Gatherer/GatherMate/Carto_<blah> at the same time, and we're back to the situation where the library is just used by 1 addon, and shouldn't have been a library at all.
Each addon can just maintain its own herbs translation, and often in a more compact way, with faster lookups than a generic library.
Unless the library maintains its own SV, like MobHealth used to do as a standalone addon, I do not think it will be very useful.
If addonA uses LibAlts-1.0 and needs to store its own SV, and addonB also uses LibAlts-1.0 and needs to store its own SV, then each addon is in effect storing its own copy of Main/Alts (since a user may be running one or both addonA/addonB). If so, then why even have a library?
This is the reason why LibInventory never took off. Any central-registry-like library needs to be a standalone addon library with its own SV (like MobHealth, yes I'm aware it is deprecated).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
That's where the problem comes. If Prat is using a mapping that another addon is providing, if the user deletes/uninstalls that addon, that mapping is gone and Prat will no longer have any main/alts data.
Hence, a central storing addon is required, and the addon should just come with the library API itself (like MobHealth). I do question whether any wow user is likely to run more than one addon that requires main/alt data. If the answer is very unlikely, then this library should not be made.
Example:
LibBabble-Herbs
It was created, as a localization library for all herbs. Guess how many addons in the world use it? One. Cartographer_Herbalism. The same applies to the ore/gas/fish babble libraries. They were created as libraries for the sake of creating them, although no other addon was likely ever going to use it.
Now you can argue that Gatherer and/or GatherMate could use the same library. But that again defeats the purpose of a shared library - its to SHARE the library so there is less memory usage, but no sane user would run Gatherer/GatherMate/Carto_<blah> at the same time, and we're back to the situation where the library is just used by 1 addon, and shouldn't have been a library at all.
Each addon can just maintain its own herbs translation, and often in a more compact way, with faster lookups than a generic library.
If addonA uses LibAlts-1.0 and needs to store its own SV, and addonB also uses LibAlts-1.0 and needs to store its own SV, then each addon is in effect storing its own copy of Main/Alts (since a user may be running one or both addonA/addonB). If so, then why even have a library?
This is the reason why LibInventory never took off. Any central-registry-like library needs to be a standalone addon library with its own SV (like MobHealth, yes I'm aware it is deprecated).