Ok - we have a situation similar to what windows was like in the 90's. DLL Hell.
For those that remember - Applications (Addons, in wow-speak) would install dll's (libraries in wow-speak) and installing one application could break another one that depended on the same dll.
As it stands, when I release one of my 2 "hardly do anything" fubar plugins, there is always a post from someone saying that they have errors from other ace mods.
Yes, i do realize that Ace2 is as yet unreleased - but thats not really a valid point, so please lets not even touch that.
I want to discuss solutions to the problem - no bitch fests or political bs. This is an actual issue, and I'd like to see what ideas people have about solving it.
However this concerns library management for addons, which is sort of a suptopic of that thread.
As i see it - there is only 1 real way to install Ace2 et. al. -> standalone. however, that is not practical for distribution to primary sites - it requires a tool (WAU, SVN) to keep the libraries updated, and also a tool in game to help the user manage things. Cosmos has both of these tools - ace really only has a command line version of an in game addon manger (no standard tool exists), and it has WAU for the out of game manager.
So...that complexity is why embedded libraries are used. but they have their own problems, slow loading, and library incompatibilities they rapidly become undesireable as you add more than one addon that uses them.
!!!libs i dont this makes sense at all in its current form, and is just a 'hack' solution to the management problem i mention.
Also, some of you appear to think people want LoD addons which take 5-10 folders in your addon directory, but you dont see why this is unappealing to some people, mostly because you use the SVN to keep your mods updated (thats why I think you dont understand this topic)
Now lets discuss some real solutions to management of addons, and their various dependancies both ingame and out of game.
I'm expecting some posts like "What problems are you having exactly", "I dont have any problems", etc. from people that dont quite get it and will want to defend the status quo. So, also post (dont bitch!!!) about some of the challenges you or your users have with managing your/thier addons.
Dont flame or bitch or defend the status quo. If you dont agree that there is a problem - dont post, just read. Ok well - lets see where this takes us.
I'm not quite sure I understand your reasoning for 'embedded libraries cause problems'. If a version bump in the library causes incompatibilities with certain mods, then it's honestly a problem with the library in question, not the entire system.
This might come across as a flame, but it's not intended as one...
Quote from sylvanaar »
Also, some of you appear to think people want LoD addons which take 5-10 folders in your addon directory, but you dont see why this is unappealing to some people, mostly because you use the SVN to keep your mods updated (thats why I think you dont understand this topic)
I don't know if you ever noticed, but "pretty addon folder" is not high on the average Ace dev's list. In nearly every case "best performance possible" is high up there. Moving sometimes-needed functionality into LoD mods is a major performance boost. If you don't like the organization options for the addon folder, you need to complain at Blizzard, it's THEIR design.
As for updating... we've got SVN and WAU... if you want to update by hand well that's your choice I guess... but even then I didn't update my mods by going thru my addons folder, I used the favorites features on the relese sites to see what mods needed updating.
This might come across as a flame, but it's not intended as one...
Not taken as one, im really quite interested in solving the problem because its obvious to me that there is one.
I was really just trying to stimulate discussion on the topic because it seems like it gets ignored.
Also, i understand about the LoD addons. what i am saying though, is that some thought needs to be put into how to manage them, instead of just passing that task along to the user. Your libraries may perform well, but they dont perform if people dont want to install them.
I just went out on a limb to give people some cover to talk about this subjext. Personally - i can just use the svn or wau, but this really isnt about me, its about the end users.
I'm not quite sure I understand your reasoning for 'embedded libraries cause problems'. If a version bump in the library causes incompatibilities with certain mods, then it's honestly a problem with the library in question, not the entire system.
Thats 'dll hell' to a T.
Im drawing a parallel to when this was happening in windows, the problem is identical in most respects. Yes it is a flaw in the system, as it once was in windows, but im not trying to be critical, im trying to be constructive.
Personally I was fine with the !!!Libs folder, however I also did have some issues from time to time, since lib updating didn't work 100%. I'm in the lucky position to be a developer and therefor I know what to do to fix this, though. On the other side I can see your issues with the normal end user.
So what should we do? I think your !!!StandaloneLibs version works best so far, it's biggest advantage is that every Lib gets updated when using WAU. Maybe WAU should get a new option: to wipe all libs folders inside the addon folders and manipulate the TOC, so that the FrameXML.log doesn't get spammed with missing files. This of course has to be in a kind of expert settings/options since it's only for people knowing exactly what this option will do and that you'll need all Libs as a standalone version.
I always liked the embedded libs stuff and I always will love this direction, so just giving the people a complete zip of all libs is no option for me.
Maintaining upgrade back-compatibility is totally upon the head of the lib dev. It might be "annoying" that old mods are getting broken, but the Lib author is who you need to be bitching at :)
That being said, look at the spread of libs we have currently... and look at who wrote each one... now look at the ones being changed a lot... now look at what ones "break" the most...
The only time a new lib can break backwards compatibility is when it changes its API, which is very much a bad practice from developpers.
Especially in LUA, I guess. I haven't done much programming in it but I skimmed the 'Programming in LUA' book online and the simple fact that you can make a given function return more values than before WITHOUT breaking backwards compatibility seems heaven sent for developpers.
I don't want this to sound like a flame either but the Ace2 Library implementation is not the dll hell of windows, MS fixed dll hell by making dll have strong names and versions, I can now have 32 copies of foo.dll as long as they are all versioned and I will usually use the latest version. The problem here is that they are not all stored in one general place like the GAC so we have multiple copies everywhere and people are getting confused. The only time you should really have a problem is in cases like AceHook-2.0 which has had some of its features depricated in Lua and is now unusable for the most part (WoW 2.0) but there is an AceHook-2.1 so developers need to adjust their code to look for the new dll.
I tend to use WAU and install everything with externals so that my AddOns are easier to manage since I have many alts, none of which seem to use the same set of AddOns. The problem I constantly have is that the script on the server that turns the SVN stuff into zip files seems to fail about 15% of the time on putting externals into the zip! If you look at an AddOn with a large amount of it's bulk in externals such as Prat, and look at http://www.wowace.com/files/index.php?path=Prat/ you can see that every so often you get zip files that are much smaller than what they should be because there are no externals packed with them. I consider the Files section to be the place I would send new users looking for an AddOn I recommend to them, but currently it's hit or miss whether they will run into a bunch of missing Libraries.
Disclaimer: I am but a lowly user. :( Feel free to ignore me!
From an end-user perspective, having embedded libraries has been sort of a nightmare. It sounds great in theory but I had no end of trouble with mods breaking other mods each time I did an update. In the end I ended up disembedding the libraries using the !!!StandaloneLibraries approach.
I don't think I'm a stupid person, and I'm fairly computer literate, but it took me awhile to figure out how to get the standalone libraries to work. Considering I run on a Mac and don't have WAU it was fairly involved. On top of that since the authors can test their mods using the embedded libraries their .toc files might be wrong. (I had to edit the toc file for one of my mods to get it to work.)
Don't get me wrong-- I think it was worth the trouble and I'm now very happy with all my Ace mods. But if something can be done to make the embedded system work better, or even to go back to not embedding libraries at all, now is the time to implement sweeping changes. Everyone's in the process of updating their mods or losing them with 2.0 anyway.
I do think you raise an interesting point there, beesknees, in that the authors are quite likely to not test their own addons in a typical user environment. If you have a !!!Libs setup and build your addon like that, there's a chance you'll screw up your .toc or your embedded libs.
I know that there's a project somewhere for a WoW emulator/development environment. It just emulates events and such, aimed squarely at add-on development. It might be interesting to run an addon through this pre-commit if it's not too hard on the server.
I do think you raise an interesting point there, beesknees, in that the authors are quite likely to not test their own addons in a typical user environment. If you have a !!!Libs setup and build your addon like that, there's a chance you'll screw up your .toc or your embedded libs.
I know that there's a project somewhere for a WoW emulator/development environment. It just emulates events and such, aimed squarely at add-on development. It might be interesting to run an addon through this pre-commit if it's not too hard on the server.
WoWBench isn't really ready for something like that, at least not the last time I checked. Perhaps someone will make a handy UnitTest framework for Ace/WoW. That would, of course, require addon and lib authors to actually write unit tests though.
I do think you raise an interesting point there, beesknees, in that the authors are quite likely to not test their own addons in a typical user environment. If you have a !!!Libs setup and build your addon like that, there's a chance you'll screw up your .toc or your embedded libs.
This is whyfor I wrote InBed, but I think I'm the only one that uses it.
The underlying issue is that we've got so damn many libs it's a bitch to manage externals.
I don't want this to sound like a flame either but the Ace2 Library implementation is not the dll hell of windows, MS fixed dll hell by making dll have strong names and versions, I can now have 32 copies of foo.dll as long as they are all versioned and I will usually use the latest version. The problem here is that they are not all stored in one general place like the GAC so we have multiple copies everywhere and people are getting confused. The only time you should really have a problem is in cases like AceHook-2.0 which has had some of its features depricated in Lua and is now unusable for the most part (WoW 2.0) but there is an AceHook-2.1 so developers need to adjust their code to look for the new dll.
Actually, you arent arguing against what im saying at all - yes they did fix dll hell, but not really with the GAC this is a link if you are interested:
Ok, what about building a !!!StandaloneLibraries zip which contains the actual libraries instead of blanks, and have it triggered by chron, say - hourly?
You could even include script files like in my example.
It would mean that authors could depend on certain libraries being on the users machine. They could embed whatever other lesser used ones with thier addond.
Is that a step i0n the right direction? Are there some better ideas?
I think part of the problem lies in some AddOns don't get re-zipped only once every bluemoon. Anyone installing one of these using WAU gets the old libs with it. Until I disembedded a couple of days ago, I would get four Ace2 errors log on - prolly from a set I where the AceAddOn version was around 14500. I know I had some older. (I know the versions were swept away, but they do get read on log-in, no?) Perhaps a script to re-package any version more older than X days/weeks might alleviate some issues.
Granted, SVN updating all you addons would prevent this, but as anyone who has been around for the last few months knows, this opens up a whole new can of worms is everyone tries...
The Standalone Libraries, if the instructions are followed, and are regularly updated along with the other addons, seems nearly effortless.
I also had my GC rate go down, but prolly not a part of this discussion.
I think the current system is fine, as long as library authors stop breaking older addons (API changes) without updating the major version number.
API changes are not the most common case, though. More common is a mod will work with embedded librariex or !!!Libs, but not both, or installing it breaks another mod.
I think the current system is fine, as long as library authors stop breaking older addons (API changes) without updating the major version number.
API changes are not the most common case, though. More common is a mod will work with embedded librariex or !!!Libs, but not both, or installing it breaks another mod.
!!!Libs is bound to be often very out of date, especially if you use the zip. if you're gonna unembed with WAU, use standalones. End users should honestly never, ever be using !!!Libs.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
For those that remember - Applications (Addons, in wow-speak) would install dll's (libraries in wow-speak) and installing one application could break another one that depended on the same dll.
As it stands, when I release one of my 2 "hardly do anything" fubar plugins, there is always a post from someone saying that they have errors from other ace mods.
Yes, i do realize that Ace2 is as yet unreleased - but thats not really a valid point, so please lets not even touch that.
I want to discuss solutions to the problem - no bitch fests or political bs. This is an actual issue, and I'd like to see what ideas people have about solving it.
This is sort of like the topic in this thread: http://www.wowace.com/forums/index.php?topic=2691.0
However this concerns library management for addons, which is sort of a suptopic of that thread.
As i see it - there is only 1 real way to install Ace2 et. al. -> standalone. however, that is not practical for distribution to primary sites - it requires a tool (WAU, SVN) to keep the libraries updated, and also a tool in game to help the user manage things. Cosmos has both of these tools - ace really only has a command line version of an in game addon manger (no standard tool exists), and it has WAU for the out of game manager.
So...that complexity is why embedded libraries are used. but they have their own problems, slow loading, and library incompatibilities they rapidly become undesireable as you add more than one addon that uses them.
!!!libs i dont this makes sense at all in its current form, and is just a 'hack' solution to the management problem i mention.
Also, some of you appear to think people want LoD addons which take 5-10 folders in your addon directory, but you dont see why this is unappealing to some people, mostly because you use the SVN to keep your mods updated (thats why I think you dont understand this topic)
Now lets discuss some real solutions to management of addons, and their various dependancies both ingame and out of game.
I'm expecting some posts like "What problems are you having exactly", "I dont have any problems", etc. from people that dont quite get it and will want to defend the status quo. So, also post (dont bitch!!!) about some of the challenges you or your users have with managing your/thier addons.
Dont flame or bitch or defend the status quo. If you dont agree that there is a problem - dont post, just read. Ok well - lets see where this takes us.
I don't know if you ever noticed, but "pretty addon folder" is not high on the average Ace dev's list. In nearly every case "best performance possible" is high up there. Moving sometimes-needed functionality into LoD mods is a major performance boost. If you don't like the organization options for the addon folder, you need to complain at Blizzard, it's THEIR design.
As for updating... we've got SVN and WAU... if you want to update by hand well that's your choice I guess... but even then I didn't update my mods by going thru my addons folder, I used the favorites features on the relese sites to see what mods needed updating.
Not taken as one, im really quite interested in solving the problem because its obvious to me that there is one.
I was really just trying to stimulate discussion on the topic because it seems like it gets ignored.
Also, i understand about the LoD addons. what i am saying though, is that some thought needs to be put into how to manage them, instead of just passing that task along to the user. Your libraries may perform well, but they dont perform if people dont want to install them.
I just went out on a limb to give people some cover to talk about this subjext. Personally - i can just use the svn or wau, but this really isnt about me, its about the end users.
Also, maybe read this post:
http://www.wowace.com/forums/index.php?topic=6.0
Thats 'dll hell' to a T.
Im drawing a parallel to when this was happening in windows, the problem is identical in most respects. Yes it is a flaw in the system, as it once was in windows, but im not trying to be critical, im trying to be constructive.
If people dont agree with me thats ok.
So what should we do? I think your !!!StandaloneLibs version works best so far, it's biggest advantage is that every Lib gets updated when using WAU. Maybe WAU should get a new option: to wipe all libs folders inside the addon folders and manipulate the TOC, so that the FrameXML.log doesn't get spammed with missing files. This of course has to be in a kind of expert settings/options since it's only for people knowing exactly what this option will do and that you'll need all Libs as a standalone version.
I always liked the embedded libs stuff and I always will love this direction, so just giving the people a complete zip of all libs is no option for me.
That being said, look at the spread of libs we have currently... and look at who wrote each one... now look at the ones being changed a lot... now look at what ones "break" the most...
Seeing a pattern? :)
Especially in LUA, I guess. I haven't done much programming in it but I skimmed the 'Programming in LUA' book online and the simple fact that you can make a given function return more values than before WITHOUT breaking backwards compatibility seems heaven sent for developpers.
From an end-user perspective, having embedded libraries has been sort of a nightmare. It sounds great in theory but I had no end of trouble with mods breaking other mods each time I did an update. In the end I ended up disembedding the libraries using the !!!StandaloneLibraries approach.
I don't think I'm a stupid person, and I'm fairly computer literate, but it took me awhile to figure out how to get the standalone libraries to work. Considering I run on a Mac and don't have WAU it was fairly involved. On top of that since the authors can test their mods using the embedded libraries their .toc files might be wrong. (I had to edit the toc file for one of my mods to get it to work.)
Don't get me wrong-- I think it was worth the trouble and I'm now very happy with all my Ace mods. But if something can be done to make the embedded system work better, or even to go back to not embedding libraries at all, now is the time to implement sweeping changes. Everyone's in the process of updating their mods or losing them with 2.0 anyway.
I know that there's a project somewhere for a WoW emulator/development environment. It just emulates events and such, aimed squarely at add-on development. It might be interesting to run an addon through this pre-commit if it's not too hard on the server.
WoWBench isn't really ready for something like that, at least not the last time I checked. Perhaps someone will make a handy UnitTest framework for Ace/WoW. That would, of course, require addon and lib authors to actually write unit tests though.
This is whyfor I wrote InBed, but I think I'm the only one that uses it.
The underlying issue is that we've got so damn many libs it's a bitch to manage externals.
Actually, you arent arguing against what im saying at all - yes they did fix dll hell, but not really with the GAC this is a link if you are interested:
http://msdn2.microsoft.com/en-us/library/aa375193.aspx
You could even include script files like in my example.
It would mean that authors could depend on certain libraries being on the users machine. They could embed whatever other lesser used ones with thier addond.
Is that a step i0n the right direction? Are there some better ideas?
Granted, SVN updating all you addons would prevent this, but as anyone who has been around for the last few months knows, this opens up a whole new can of worms is everyone tries...
The Standalone Libraries, if the instructions are followed, and are regularly updated along with the other addons, seems nearly effortless.
I also had my GC rate go down, but prolly not a part of this discussion.
API changes are not the most common case, though. More common is a mod will work with embedded librariex or !!!Libs, but not both, or installing it breaks another mod.