If Tekkub does not want there to be a standalone version of LDB then he should tell authors to disable nolib zips for their addons using "enable-nolib-creation: no" not by encouraging hard embedding of the library.
But then what happens if they're embedding big ass-libraries that DO benefit from standalones and no-lib versions? I'm all for the end of standalones (I feel they go against the embed design, if the user has to think about the libs, something is wrong)... but standalones exist because with larger libraries there is a significant performance improvement. No, I don't want people no-libing LDB, but I understand why they would want to do it with other libs.
Yes, if you ONLY use LDB, then disable no-lib packaging. But I don't think anyone besides me is using LDB and without some no-lib-friendly embeds as well.
I support the idea of allowing libraries to be specified as not having standalone versions and always being included in nolib zips because of LibStub and CallbackHandler, but since I have been fighting for that since WoWAce moved to the CurseForge system and there has been no sign of anybody with the power to make that change supporting the idea so I see it as a lost cause.
It sounds to me like no one ever forced the issue, or maybe that someone just caved and made standalones for LS and CBH (without permission?). Well LDB certainly has some weight behind it, and this is how the lib has been for a year now, so maybe I can motivate some changes? I mean, all in all, I want lib authors to be taking into account the cost of loading up their library, and designing things such that standalone versions have no significant performance improvement, so this whole mess of standalones can go away (probably with the exception of Ace3). The embed design is a wonderful one, we CAN make it work better.
The trunk versions of LibStub and CBH may have toc's but they are still not standalones since nothing OptDeps them, they do not get loaded first as a proper standalone does.
I pushed and pushed the issue of nolibs not having LibStub and CBH in them but was completely ignored.
Oh blissful ignorance, I haven't signed on for the point rewards, and don't intend to. I have no idea how the system works or could be "used". If I don't forget I give 100% splits to coauthors in case they care for points. (if you are coauthor on any of my projects, ping me if I forgot and you care).
Any automatic point system is bound to reward a certain kind of strategy... not the fault of the player to play that strategy, but of the system to be set up that way!
Really points should go to the many people who brainstormed LDB in its formative time, in fact the original concept wasn't even tek's. He was the one who'd harden a particular instantiation of what was discussed. http://forums.wowace.com/showthread.php?t=10236. Should Elk get all points for having the original idea? Or should points be distributed by amount posted in discussion? Or should points be given who ends up leading the project of the final version? Or should Orion get all points for posting the first design with spec? Or Borlox partial credit for early broker prototypes? Or Elk or andreasg or josh_borke? Points are funny in a community effort environment...
On the embed issue, way too dogmatic for my taste, but yeah I've been around long enough to know that things swing that way at times around here. The harm of LDB not being hard-embedded is pretty much zero except for that it might crack some hard skulls soft and violate some unreasoned and unreasonable "principles".
But yeah it's kind of fun to try to force others to live by ones own belief (or point!) system.
Elk gets 1/3 of the points, since he actually put forth the effort to make LDB-1.0. It might sound harsh, but I think points go for actual coding effort, not sitting around talking about design. I had my say in Ace3's designs, but didn't really give any code. I don't get points for it. I don't expect any points for it. Seems simple enough for me.
Not that there's some abundance of points to toss around here anyway. Today I got 2.25 points for LDB. I got 3.33 for my OLD gratuity lib... the one that's been "mature" for like 3 years.
And who's forcing who to do what? I'm not imposing my design beliefs on any other lib. I'm not telling people how they HAVE to setup .pkgmeta so I get points. I've merely asked, and given the best instructions on doing it without breaking things that I can. Anyone who does set up the relationship is just extra nice.
I really don't see how this is "playing" the system at all. The system rewards library authors when their code is used, just as it rewards addon authors when their code is used. Look at ckk, he's got a metric ass-tonne of libs, and he gets a lot of points from them because he has a big install base. Look at Ace2 and Ace3, they're earning a lot of people a lot of points... I don't even get points for Ace2 and I wrote a lot of code for it, way back "in the day". If I wanted to roll in the points, I'd be getting bitchy to get credit for Ace2, not asking dozens of addon authors to update their little plugins to give me points.
In my opinion, only LDB display addons should include the LDB library.
All LDB data supplying authors should just write that addon with optional LDB support. Because, after all, LDB objects without a display addon isn't very useful. As any user is unlikely to run more than 1 or 2 LDB display addons at the same time, the user would only load a single copy of LDB from his single display addon, and then all other LDB data supplying addons create their plugins after VARIABLES_LOADED or PLAYER_LOGIN (which happens after the display addon has loaded which implies LDB is present and loaded).
For example, most of my addons provide optional LDB support, but doesn't actually include LDB itself. If the user has a LDB display addon, it would naturally include LDB, and my LDB objects would then get created. Either way, I would also typically GC away the LDB data object creation code.
This would mean 2 things:
1. LDB is minimally packaged once in a display addon, and a user only needs to load it once. Not 20 times from 20 LDB addons.
2. Any LDB lib updates would then require the display addon to update it. But LDB has been stable and mature enough with no changes in the last year.
This has been somewhat an issue with the old FuBarPlugin-2.0. Technically, almost no FuBar plugin ever needed to embed that library (which also meant embedding a fuckton of other supporting libs such as AceEvent, AceLibrary, AceOO that it required) because the user would also naturally have FuBar installed anyway, and it comes with the lib. The main reason why it wasn't done that way was because FuBarPlugin-2.0 also worked standalone without FuBar to create a minimap button instead.
Let alone addons that have no use without LDB (Broker_*), I see two issues with your proposal Xinhuan:
1) LDB should be loaded before the addons could use it. Given that there exist several displays, should they be all listed in the OptDeps ? In other words, how do I ensure LDB is loaded before creating my dataobject ?
2) LibDBIcon allows a standalone use of LDB.
I admit that if the point 1 could be fixed, optional LDB support is an interesting idea.
Point 1 is, of course, the problem. A custom TOC field that indicated the addon was an LDB display of a certain type could work, but then every addon providing "optional" support would need extra logic to scan addon TOC to find a display, that was enabled, and force it to load. Is that extra code worth it just to drop the library code?
Oh and of course there's point 3: addons that use LDB but don't use the data or launcher specs :)
*edit*
Actually I just had a thought... if LDB isn't present, a global table could be made, DO tables created inside it, and then when LDB does load, have it remove those tables and register them as DOs (you can already register an existing table as a DO anyway). That would be a minimal change to both addons and the lib. Basically the same thing as how clique and company track unitframes to be cliqueable'd
I don't think there's anything wrong with the current design of needing the library to be present before using it. It also seems strange that there is any concern at all about loading multiple copies of LDB when you're so strongly against disembedding, and obviously not concerned about loading multiple copies of other, much larger libraries. :p
About that thought: how would the addon using the global table be notified its table has been LDB'ed ? And what about LDB callbacks ?
why would a addon care if the table got LDB'ed it would just post updates to it as normal but instead of going just to the gloabl table LDB would have picked up on it and started making a true DO out of it
this is actually a pretty sweet idea
all you would have to do to "register" a DO is do the following
LDBtable = LDBtable or {} -- makes a new table if it doesn't already exist
LDBtable['DOname'] = { -- creates a DO with name DOname
icon = 'icon//path'
label = "lbl",
type = "data source",
text = "some text",
}
local obj = LDBtable['DOname'] -- pull in a local reference to your DO
If the addon cares about callbacks than it's most likely a display, and should just embed the lib. A datasource wouldn't care, it'd just make it's table and write into it. If LDB loaded, then the table is a DO and will fire callbacks. If LDB isn't loaded, it's just a table they're writing to that noone cares about.
I don't think there's anything wrong with the current design of needing the library to be present before using it. It also seems strange that there is any concern at all about loading multiple copies of LDB when you're so strongly against disembedding, and obviously not concerned about loading multiple copies of other, much larger libraries. :p
I'm not concerned about multiple copies, I mean, the primary design of LDB was to be as minimal as possible. But if the lib doesn't need to be embedded for an addon to support it, then even more authors would be willing to add optional support to their addons. The less code they have to add, the better things are for support.
I don't think bumping the major version would be good though. Seeing as only displays would need to update to add support, forcing everyone across teh board to upgrade the lib wouldn't be good. Besides that, it's like one little loop to add to the lib's loadtime, it wouldn't change any functionality.
yss, actually I was thinging more like...
local obj = {}
if (ldb) then obj = ldb:Register("name", obj) else LDB_REGISTRY = LDB_REGISTRY or {}; LDB_REGISTRY["name"] = obj end
Initially I was enthusiastic about this idea but really it's just unnecessary. LDB is much more general in principle than a dumb an unresponsive Do on one side and a smart reactive display on the other. By adding the
registry things are just unnecessarily complicated. LDB is so slim that loading it many times means little and saving the complication for the authors is well worth the time. If this is about points screw that. Libs really should just make sense and Ldb makes sense as is, which is a table interface with registration and write-activated callbacks. And all parties should just grab the lib to interface. If there is a strong desire to specialize for the most common use case (ie complete assymmetry with respect to reading and writing), then let's just write a lib that really just does that. Just have a global registry for dummies and let the smart side do everything.
Let alone addons that have no use without LDB (Broker_*), I see two issues with your proposal Xinhuan:
1) LDB should be loaded before the addons could use it. Given that there exist several displays, should they be all listed in the OptDeps ? In other words, how do I ensure LDB is loaded before creating my dataobject ?
2) LibDBIcon allows a standalone use of LDB.
I admit that if the point 1 could be fixed, optional LDB support is an interesting idea.
1) No need to optdep anything. Addons only check for LDB's presence/absence during VARIABLES_LOADED or PLAYER_LOGIN, which only fire after all non-LOD addons have loaded. A LDB display addon should be non-LoD, since after all, it is displaying data constantly and should be loaded all the time.
If it is LoD (such as delayed addon loader), then addons would have to add unnecessary ADDON_LOADED checks, or disable the LoD portion.
2) LibDBIcon is just a standalone lib that hard embeds LDB. A wrapper lib so-to-speak, with a minimap icon creation function. There really isn't anything to prevent someone else from creating a wrapper lib around LDB to make it standalone right?
This code is in function Omen:PLAYER_LOGIN(), which is really lots of optional checks.
[php]
-- LDB launcher
if LDB then
OmenLauncher = LDB:NewDataObject("Omen", {
type = "launcher",
icon = "Interface\\AddOns\\Omen\\icon",
OnClick = function(clickedframe, button)
if button == "RightButton" then Omen:ShowConfig() else Omen:Toggle() end
end,
OnTooltipShow = function(tt)
tt:AddLine(self.defaultTitle)
tt:AddLine("|cffffff00" .. L["Click|r to toggle the Omen window"])
tt:AddLine("|cffffff00" .. L["Right-click|r to open the options menu"])
end,
})
if LDBIcon and not IsAddOnLoaded("Broker2FuBar") and not IsAddOnLoaded("FuBar") then
LDBIcon:Register("Omen", OmenLauncher, db.MinimapIcon)
end
end
[/php]
The function Omen:PLAYER_LOGIN() also contains other optional addon support such as !ClassColors and FuBarPlugin-3.0. This would also be the place where I would add in OneClickConfig support.
Again, there is no need to optdep a library that you optionally support.
Not exactly. LibDBIcon covers the tooltip and clicking functionality, so it will serve launchers but you cannot properly handle .text updates and the like, in a minimap button. It's kind of ironic that we would even mention this as an alternative, since one of the original arguments that spawned LDB was getting rid of the "minimap herpes" produced by LFB, if the display addon was not present.
I also feel that the whole issue has been blown way out of proportion. Obviously if one is using LDB to provide optional features in an addon that is/was designed to work as standalone, then he does not *need* to embed it. He can just optionally include the code in the way Xinhuan has suggested, or make it a LoD addon harddeped to the "parent" that will only be loaded if the user desires it (and he can handle the freaking embed any way he likes it). In that case, imho, using LibDBIcon does have a purpose. But "forcing" LDB specific plugins, that are actually designed for the sole purpose of updating those attributes, to now also register their objects in a global table, just in case LDB isn't present, for the sake of not embedding it, so we don't have to work around the WowAce packager system (which we shouldn't need to do in the first place), is mind-boggling. There is no significant benefit or any special reason to do so, especially if said plugins are not even hosted here.
1) No need to optdep anything. Addons only check for LDB's presence/absence during VARIABLES_LOADED or PLAYER_LOGIN, which only fire after all non-LOD addons have loaded.
Actually some of my addons aren't using AceAddon nor listening to PLAYER_LOGIN or VARIABLES_LOADED, because they don't need to. In these case the DOs are just built at loading. I think I'll have to keep LDB embedded for these ones.
Actually some of my addons aren't using AceAddon nor listening to PLAYER_LOGIN or VARIABLES_LOADED, because they don't need to. In these case the DOs are just built at loading. I think I'll have to keep LDB embedded for these ones.
My point here is, there is absolutely no harm in moving your DO creation to VARIABLES_LOADED or PLAYER_LOGIN instead of just creating them directly in the main chunk.
If your addon isn't using AceAddon, is it really that difficult to create a frame to listen for it? A frame only uses some 100 bytes of memory. Oh noes... 100 bytes.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
But then what happens if they're embedding big ass-libraries that DO benefit from standalones and no-lib versions? I'm all for the end of standalones (I feel they go against the embed design, if the user has to think about the libs, something is wrong)... but standalones exist because with larger libraries there is a significant performance improvement. No, I don't want people no-libing LDB, but I understand why they would want to do it with other libs.
Yes, if you ONLY use LDB, then disable no-lib packaging. But I don't think anyone besides me is using LDB and without some no-lib-friendly embeds as well.
It sounds to me like no one ever forced the issue, or maybe that someone just caved and made standalones for LS and CBH (without permission?). Well LDB certainly has some weight behind it, and this is how the lib has been for a year now, so maybe I can motivate some changes? I mean, all in all, I want lib authors to be taking into account the cost of loading up their library, and designing things such that standalone versions have no significant performance improvement, so this whole mess of standalones can go away (probably with the exception of Ace3). The embed design is a wonderful one, we CAN make it work better.
I pushed and pushed the issue of nolibs not having LibStub and CBH in them but was completely ignored.
Any automatic point system is bound to reward a certain kind of strategy... not the fault of the player to play that strategy, but of the system to be set up that way!
Really points should go to the many people who brainstormed LDB in its formative time, in fact the original concept wasn't even tek's. He was the one who'd harden a particular instantiation of what was discussed. http://forums.wowace.com/showthread.php?t=10236. Should Elk get all points for having the original idea? Or should points be distributed by amount posted in discussion? Or should points be given who ends up leading the project of the final version? Or should Orion get all points for posting the first design with spec? Or Borlox partial credit for early broker prototypes? Or Elk or andreasg or josh_borke? Points are funny in a community effort environment...
On the embed issue, way too dogmatic for my taste, but yeah I've been around long enough to know that things swing that way at times around here. The harm of LDB not being hard-embedded is pretty much zero except for that it might crack some hard skulls soft and violate some unreasoned and unreasonable "principles".
But yeah it's kind of fun to try to force others to live by ones own belief (or point!) system.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumwow that thread drags up old memories...
Not that there's some abundance of points to toss around here anyway. Today I got 2.25 points for LDB. I got 3.33 for my OLD gratuity lib... the one that's been "mature" for like 3 years.
And who's forcing who to do what? I'm not imposing my design beliefs on any other lib. I'm not telling people how they HAVE to setup .pkgmeta so I get points. I've merely asked, and given the best instructions on doing it without breaking things that I can. Anyone who does set up the relationship is just extra nice.
I really don't see how this is "playing" the system at all. The system rewards library authors when their code is used, just as it rewards addon authors when their code is used. Look at ckk, he's got a metric ass-tonne of libs, and he gets a lot of points from them because he has a big install base. Look at Ace2 and Ace3, they're earning a lot of people a lot of points... I don't even get points for Ace2 and I wrote a lot of code for it, way back "in the day". If I wanted to roll in the points, I'd be getting bitchy to get credit for Ace2, not asking dozens of addon authors to update their little plugins to give me points.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAll LDB data supplying authors should just write that addon with optional LDB support. Because, after all, LDB objects without a display addon isn't very useful. As any user is unlikely to run more than 1 or 2 LDB display addons at the same time, the user would only load a single copy of LDB from his single display addon, and then all other LDB data supplying addons create their plugins after VARIABLES_LOADED or PLAYER_LOGIN (which happens after the display addon has loaded which implies LDB is present and loaded).
For example, most of my addons provide optional LDB support, but doesn't actually include LDB itself. If the user has a LDB display addon, it would naturally include LDB, and my LDB objects would then get created. Either way, I would also typically GC away the LDB data object creation code.
This would mean 2 things:
1. LDB is minimally packaged once in a display addon, and a user only needs to load it once. Not 20 times from 20 LDB addons.
2. Any LDB lib updates would then require the display addon to update it. But LDB has been stable and mature enough with no changes in the last year.
This has been somewhat an issue with the old FuBarPlugin-2.0. Technically, almost no FuBar plugin ever needed to embed that library (which also meant embedding a fuckton of other supporting libs such as AceEvent, AceLibrary, AceOO that it required) because the user would also naturally have FuBar installed anyway, and it comes with the lib. The main reason why it wasn't done that way was because FuBarPlugin-2.0 also worked standalone without FuBar to create a minimap button instead.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) LDB should be loaded before the addons could use it. Given that there exist several displays, should they be all listed in the OptDeps ? In other words, how do I ensure LDB is loaded before creating my dataobject ?
2) LibDBIcon allows a standalone use of LDB.
I admit that if the point 1 could be fixed, optional LDB support is an interesting idea.
Oh and of course there's point 3: addons that use LDB but don't use the data or launcher specs :)
*edit*
Actually I just had a thought... if LDB isn't present, a global table could be made, DO tables created inside it, and then when LDB does load, have it remove those tables and register them as DOs (you can already register an existing table as a DO anyway). That would be a minimal change to both addons and the lib. Basically the same thing as how clique and company track unitframes to be cliqueable'd
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumwhy would a addon care if the table got LDB'ed it would just post updates to it as normal but instead of going just to the gloabl table LDB would have picked up on it and started making a true DO out of it
this is actually a pretty sweet idea
all you would have to do to "register" a DO is do the following
LDBtable = LDBtable or {} -- makes a new table if it doesn't already exist LDBtable['DOname'] = { -- creates a DO with name DOname icon = 'icon//path' label = "lbl", type = "data source", text = "some text", } local obj = LDBtable['DOname'] -- pull in a local reference to your DOthe LDB takes care of the rest
I'm not concerned about multiple copies, I mean, the primary design of LDB was to be as minimal as possible. But if the lib doesn't need to be embedded for an addon to support it, then even more authors would be willing to add optional support to their addons. The less code they have to add, the better things are for support.
I don't think bumping the major version would be good though. Seeing as only displays would need to update to add support, forcing everyone across teh board to upgrade the lib wouldn't be good. Besides that, it's like one little loop to add to the lib's loadtime, it wouldn't change any functionality.
yss, actually I was thinging more like...
local obj = {}
if (ldb) then obj = ldb:Register("name", obj) else LDB_REGISTRY = LDB_REGISTRY or {}; LDB_REGISTRY["name"] = obj end
registry things are just unnecessarily complicated. LDB is so slim that loading it many times means little and saving the complication for the authors is well worth the time. If this is about points screw that. Libs really should just make sense and Ldb makes sense as is, which is a table interface with registration and write-activated callbacks. And all parties should just grab the lib to interface. If there is a strong desire to specialize for the most common use case (ie complete assymmetry with respect to reading and writing), then let's just write a lib that really just does that. Just have a global registry for dummies and let the smart side do everything.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) No need to optdep anything. Addons only check for LDB's presence/absence during VARIABLES_LOADED or PLAYER_LOGIN, which only fire after all non-LOD addons have loaded. A LDB display addon should be non-LoD, since after all, it is displaying data constantly and should be loaded all the time.
If it is LoD (such as delayed addon loader), then addons would have to add unnecessary ADDON_LOADED checks, or disable the LoD portion.
2) LibDBIcon is just a standalone lib that hard embeds LDB. A wrapper lib so-to-speak, with a minimap icon creation function. There really isn't anything to prevent someone else from creating a wrapper lib around LDB to make it standalone right?
This code is in function Omen:PLAYER_LOGIN(), which is really lots of optional checks.
[php]
-- LDB launcher
if LDB then
OmenLauncher = LDB:NewDataObject("Omen", {
type = "launcher",
icon = "Interface\\AddOns\\Omen\\icon",
OnClick = function(clickedframe, button)
if button == "RightButton" then Omen:ShowConfig() else Omen:Toggle() end
end,
OnTooltipShow = function(tt)
tt:AddLine(self.defaultTitle)
tt:AddLine("|cffffff00" .. L["Click|r to toggle the Omen window"])
tt:AddLine("|cffffff00" .. L["Right-click|r to open the options menu"])
end,
})
if LDBIcon and not IsAddOnLoaded("Broker2FuBar") and not IsAddOnLoaded("FuBar") then
LDBIcon:Register("Omen", OmenLauncher, db.MinimapIcon)
end
end
[/php]
The function Omen:PLAYER_LOGIN() also contains other optional addon support such as !ClassColors and FuBarPlugin-3.0. This would also be the place where I would add in OneClickConfig support.
Again, there is no need to optdep a library that you optionally support.
Not exactly. LibDBIcon covers the tooltip and clicking functionality, so it will serve launchers but you cannot properly handle .text updates and the like, in a minimap button. It's kind of ironic that we would even mention this as an alternative, since one of the original arguments that spawned LDB was getting rid of the "minimap herpes" produced by LFB, if the display addon was not present.
I also feel that the whole issue has been blown way out of proportion. Obviously if one is using LDB to provide optional features in an addon that is/was designed to work as standalone, then he does not *need* to embed it. He can just optionally include the code in the way Xinhuan has suggested, or make it a LoD addon harddeped to the "parent" that will only be loaded if the user desires it (and he can handle the freaking embed any way he likes it). In that case, imho, using LibDBIcon does have a purpose. But "forcing" LDB specific plugins, that are actually designed for the sole purpose of updating those attributes, to now also register their objects in a global table, just in case LDB isn't present, for the sake of not embedding it, so we don't have to work around the WowAce packager system (which we shouldn't need to do in the first place), is mind-boggling. There is no significant benefit or any special reason to do so, especially if said plugins are not even hosted here.
My display is AL delayed load :P
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumActually some of my addons aren't using AceAddon nor listening to PLAYER_LOGIN or VARIABLES_LOADED, because they don't need to. In these case the DOs are just built at loading. I think I'll have to keep LDB embedded for these ones.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMy point here is, there is absolutely no harm in moving your DO creation to VARIABLES_LOADED or PLAYER_LOGIN instead of just creating them directly in the main chunk.
If your addon isn't using AceAddon, is it really that difficult to create a frame to listen for it? A frame only uses some 100 bytes of memory. Oh noes... 100 bytes.