The library is just a registry, individual addons would need to provide the actual sv storage.
Unfortunately I think that makes this less useful than it could be. If I decide to switch from Chatter to Prat, I'd lose all my alt names anyways since they'd be using different saved variables.
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).
A common API for accessing the data from any number of addons which may be collecting it. This lets you combine data from multiple sources. If you need a storage addon you can make one. Same concept as sharedmedia. It just provides a way for an addon to expose its internal data without creating a dependency for the addon using the data.
Unfortunately I think that makes this less useful than it could be. If I decide to switch from Chatter to Prat, I'd lose all my alt names anyways since they'd be using different saved variables.
You could say make a standalone addon for your guild which loads all the data from a static table included in the addon.
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.
I'd like to echo Pasta's concerns. Most end-users would never think to run two chat addons (as an example) at once in order to migrate the data, and it may not even work because errors will likely result from running two full-featured chat addons at the same time.
I do really like the idea of providing a centralized registry for alt data though.
I'd like to echo Pasta's concerns. Most end-users would never think to run two chat addons (as an example) at once in order to migrate the data, and it may not even work because errors will likely result from running two full-featured chat addons at the same time.
I do really like the idea of providing a centralized registry for alt data though.
Its not about storing the data, just exposing it for other addons to use.
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.
It makes it easier to create addons that plug into each other for that data, yes. However, when it comes to figuring out which addon is actually storing the data and how to migrate it to an alternative, users aren't much better off. Basically, I feel that while it opens up opportunities for addon developers, it's also passing up an opportunity to free users from reliance on a particular chat addon or whatever.
As a user I also wouldn't want the alt data to be stored by my chat addon anyways given the choice, since they generally have horrible interfaces for defining lists of alts compared to, say, GuildGreet. It would be much better to have the data stored by an addon that is dedicated to providing a user-friendly UI for building and managing the alt data.
I feel that the idea as proposed would realistically force any addon using the library to maintain its own copy of the entire data set in order to avoid the inevitable issues resulting from users switching from one addon to another and all of a sudden losing their alt data because some random addon was the one maintaining the list. The same issue happens now when you rip out an addon that was providing a particular font or bar texture via SharedMedia, and it's damned annoying, so I don't know why it's being held up as something that can't be improved upon - especially when you consider the fact that we're talking about data and not static files in addon folders.
Edit: In response to Xinhuan's post: I think it's a good idea because it would allow people to create separate addons for creating and managing the data, as chat addons seem to generally have very minimal interfaces for that sort of thing. There are also other, non-chat-addon-related uses for such data; see GuildGreet as an example.
I agree that the most powerful implementation would be HunterZ's recommendation. Create an addon that is an alt manager, with an API that other addons can plug into. Other addons can then opdep the Alts addon, and if it isn't present, either not expose that functionality, or use their own built-in functionality.
I think making individual addons do persistence of the data really hobbles it pretty badly. There isn't really a compelling reason to use it in that case; it'd be better to just define a standard API for addons to implement for geteting alts, rather than throwing another lib into the mix. Right now, the list of mods exposing alt data is very small, so a standard API for other mods to implement seems like it'd be easier all around. That said, I think a generalized alt manager would go over extremely well.
I also agree that the library should store the data rather than force addons to store it. Then there would be only one alts table for various addons to use, rather than, say, Prat storing the table, GuildGreet storing the table, some raid manager storing the table, a guild list organizer storing the table, etc. This defeats the purpose of a shared library, and they may as well use their own methods of creating/storing that data. Instead, the lib will store the table and the mods will access/write to it directly. One centralized location of the data for the mods to share.
Of course, this does require the user to install the library as standalone. Each mod that would use LibAlts would have to have a fallback in case a user did not have LibAlts installed. Having it installed would just be a bonus to the user, in that they would be able to share alt data across all addons they have installed that utilize it. Perhaps LibAlts could have its own frame to enter alt information as well - a centralized place to enter alt names into the table...
Ok, you can now find "AltsMains" in the projects, and working. It uses libalts-1.0 as its interface. Anything you stuff into libalts will be saved by AltsMains. Onload, it stuff everything it knows about back into libalts-1.0 for use by your addons.
Notes:
* All names are stored in lowercase. Since there is no real validation done to determine if the names you sent to libalts are actually valid players, it really doesn't make a difference, does it.
I do like the idea of this, in fact I would like to see something comparable for bag/bank storage across alts, trade professions etc.
Right now when swapping between specific solutions for these I lose data, where with a "data hub" type solution one could migrate much more conveniently between front ends.
I do like the idea of this, in fact I would like to see something comparable for bag/bank storage across alts, trade professions etc.
Right now when swapping between specific solutions for these I lose data, where with a "data hub" type solution one could migrate much more conveniently between front ends.
Well, for bag/bank there's been a few. OneStorage and SanityItemCache come to mind.
what, GloryLib method not liked any more? (Being that the addon embedding it was responsible for adding the lib's SV to it's toc requirements)
Are the variables loaded once for all addons ? or once per addons ? If the same variable is registered multiple time, is it written in every addons SV (i.e. multiple copies of the same variables) ? What happens if the variable is stored in addonA SV and addonA is disabled ? I'm curious to know how all this resolves.
Are the variables loaded once for all addons ? or once per addons ? If the same variable is registered multiple time, is it written in every addons SV (i.e. multiple copies of the same variables) ? What happens if the variable is stored in addonA SV and addonA is disabled ? I'm curious to know how all this resolves.
not nicely if thats what your wondering...it was a hori-bad way of doing things...
I also agree that the library should store the data rather than force addons to store it. Then there would be only one alts table for various addons to use, rather than, say, Prat storing the table, GuildGreet storing the table, some raid manager storing the table, a guild list organizer storing the table, etc. This defeats the purpose of a shared library, and they may as well use their own methods of creating/storing that data. Instead, the lib will store the table and the mods will access/write to it directly. One centralized location of the data for the mods to share.
Of course, this does require the user to install the library as standalone. Each mod that would use LibAlts would have to have a fallback in case a user did not have LibAlts installed. Having it installed would just be a bonus to the user, in that they would be able to share alt data across all addons they have installed that utilize it. Perhaps LibAlts could have its own frame to enter alt information as well - a centralized place to enter alt names into the table...
LibAlts-1.0 is about accessing the data. Zhinjio's library is about storing the data. They compliment each other.
With LibAlts-1.0 the goal was not to force existing addons to change how they store thier data internally. Just to allow others to access thier data without creating dependancies.
So (like sharedmedia, and libsharedmedia):
LibAlts-1.0 - Access shared alt information
AltsMains - Provide data for LibAlts-1.0
On the humorous side, theres some irony in me creating a minimal functionality library, and people saying it doesn't do enough. (Since I am not known for writing things with minimal functionality.)
I've got some good ideas in my head for a GUI frontend for managing LibAlts data, but it will likely take some time as I'm studying Ace3 tutorials and looking at other addons and such to figure out how to implement things.
I'd like to use the BlizOptions addon config GUI, but that would prevent the user from viewing the social panel to look at notes, ranks, etc. while interacting with my addon :(
local mainName = GetMainName("SomeAlt")
local alts = { GetAltNames("SomeMain") }
Now you maintain your own SVs, and you can have multiple addons providing data, and the API is lolminimal.
An implementation would be something along the lines of:
local oldGetMainName = GetMainName or function() return end
function GetMainName(name)
if myAddon.db.chars[name] and myAddon.db.chars[name].main then
return myAddon.db.chars[name].main
else
return oldGetMainName(name)
end
end
Tadaa?
(Note "return" vs "return nil", which becomes important for alt names. "return nil" = 1 entry with nil in it. "return" = 0 values.)
Edit: Oh, and addons both providing and displaying main/alt data, e.g. Prat/Chatter, should of course call GetMainName() themselves, not only look in their own SVs.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGetAlts(main) - Get a list of alts for a given name
GetMain(alt) - Get the main character associated with a given name
IsMain(name) - Is the given name a main character
IsAlt(name) - Is the given name an alternate character
The last 2 methods are more for convienience.
Internally storage would be a table of tables:
Alts[main] = { alt1, alt2, alt3 }The library is just a registry, individual addons would need to provide the actual sv storage.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumUnfortunately I think that makes this less useful than it could be. If I decide to switch from Chatter to Prat, I'd lose all my alt names anyways since they'd be using different saved variables.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf 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).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou could say make a standalone addon for your guild which loads all the data from a static table included in the addon.
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.
I do really like the idea of providing a centralized registry for alt data though.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIts not about storing the data, just exposing it for other addons to use.
So, other addons dont need to do:
if Prat then
...
elseif Chatter then
...
end
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat'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.
As a user I also wouldn't want the alt data to be stored by my chat addon anyways given the choice, since they generally have horrible interfaces for defining lists of alts compared to, say, GuildGreet. It would be much better to have the data stored by an addon that is dedicated to providing a user-friendly UI for building and managing the alt data.
I feel that the idea as proposed would realistically force any addon using the library to maintain its own copy of the entire data set in order to avoid the inevitable issues resulting from users switching from one addon to another and all of a sudden losing their alt data because some random addon was the one maintaining the list. The same issue happens now when you rip out an addon that was providing a particular font or bar texture via SharedMedia, and it's damned annoying, so I don't know why it's being held up as something that can't be improved upon - especially when you consider the fact that we're talking about data and not static files in addon folders.
Edit: In response to Xinhuan's post: I think it's a good idea because it would allow people to create separate addons for creating and managing the data, as chat addons seem to generally have very minimal interfaces for that sort of thing. There are also other, non-chat-addon-related uses for such data; see GuildGreet as an example.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think making individual addons do persistence of the data really hobbles it pretty badly. There isn't really a compelling reason to use it in that case; it'd be better to just define a standard API for addons to implement for geteting alts, rather than throwing another lib into the mix. Right now, the list of mods exposing alt data is very small, so a standard API for other mods to implement seems like it'd be easier all around. That said, I think a generalized alt manager would go over extremely well.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOf course, this does require the user to install the library as standalone. Each mod that would use LibAlts would have to have a fallback in case a user did not have LibAlts installed. Having it installed would just be a bonus to the user, in that they would be able to share alt data across all addons they have installed that utilize it. Perhaps LibAlts could have its own frame to enter alt information as well - a centralized place to enter alt names into the table...
Notes:
* All names are stored in lowercase. Since there is no real validation done to determine if the names you sent to libalts are actually valid players, it really doesn't make a difference, does it.
* alt/main relationships are stored realm-wide.
Cheers,
- ZJ
Right now when swapping between specific solutions for these I lose data, where with a "data hub" type solution one could migrate much more conveniently between front ends.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell, for bag/bank there's been a few. OneStorage and SanityItemCache come to mind.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAre the variables loaded once for all addons ? or once per addons ? If the same variable is registered multiple time, is it written in every addons SV (i.e. multiple copies of the same variables) ? What happens if the variable is stored in addonA SV and addonA is disabled ? I'm curious to know how all this resolves.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumnot nicely if thats what your wondering...it was a hori-bad way of doing things...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLibAlts-1.0 is about accessing the data. Zhinjio's library is about storing the data. They compliment each other.
With LibAlts-1.0 the goal was not to force existing addons to change how they store thier data internally. Just to allow others to access thier data without creating dependancies.
So (like sharedmedia, and libsharedmedia):
LibAlts-1.0 - Access shared alt information
AltsMains - Provide data for LibAlts-1.0
On the humorous side, theres some irony in me creating a minimal functionality library, and people saying it doesn't do enough. (Since I am not known for writing things with minimal functionality.)
I'd like to use the BlizOptions addon config GUI, but that would prevent the user from viewing the social panel to look at notes, ranks, etc. while interacting with my addon :(
local mainName = GetMainName("SomeAlt")
local alts = { GetAltNames("SomeMain") }
Now you maintain your own SVs, and you can have multiple addons providing data, and the API is lolminimal.
An implementation would be something along the lines of:
local oldGetMainName = GetMainName or function() return end function GetMainName(name) if myAddon.db.chars[name] and myAddon.db.chars[name].main then return myAddon.db.chars[name].main else return oldGetMainName(name) end endTadaa?
(Note "return" vs "return nil", which becomes important for alt names. "return nil" = 1 entry with nil in it. "return" = 0 values.)
Edit: Oh, and addons both providing and displaying main/alt data, e.g. Prat/Chatter, should of course call GetMainName() themselves, not only look in their own SVs.