Originally Posted by Seerah
LibMediaProvider only comes with media contained in the game files by default. If anyone wants to create an extra package of media for the library to pull from, that is a separately installed addon.
For databases, just like the library code, only one set will be retained in memory. The rest will not be. If your hard drive has 500GB on it, I don't see how 1MB makes a difference. If your computer has 8GB of RAM, I don't see how 1MB of static memory makes a difference (it will even disappear when the garbage collector runs next).
Now this is not true. ZAM_Stats is a framework - an addon with an open API so that additional plugins may be created for and installed with it. It is in no way a library.
I never said that I don't use saved variables. I said that I don't use ZOS's special saved variables API. Whatever the name of your saved variable is in the .txt file, whatever you set that to in your code, that variable will be saved upon /reloadui or logout. It works the exact same way in WoW.
|
What LibMediaProvider does and what all possible addons might do are two totally different topics. I was using media generically, i.e. movies, pictures and sound, and not referring specifically to LibMediaProvider. More generally I meant if a library is physically large it should be distributed separately. Media files is the only thing I can think of that might be large. Scripts certainly are not going to be. Databases could be. I think, in general, an addon should be standalone with no dependencies, but there's one exception. I wasn't talking about 1MB, but hundreds of megabytes.
With ZAM Stats it's a matter of opinion. The author could have distributed it as a library. There is absolutely nothing preventing him from doing so. We seem to both agree that's an exception and he really shouldn't have. Whether we call a framework a special type of library that is in no way a library or makes not a bit of difference to the point. My point is that the standard should be whether a user directly interacts with the addon independent of any addon using it. ZAM Stats is a prime example of that. You have configuration options that apply to all addons. It makes no sense to have 20 paths to that because you have 20 panels installed. It only makes intuitive sense to a user to configure those 20 panels through one addon that is ZAM Stats. My opinion though is it's a library, a framework is a library, a particular type of library. One of the two types of libraries it is preferable a developer distribute standalone. Physically large ones being the other exception.
I didn't know that about saved variables. Personally, it shouldn't be so. The only that should be accessible is what an addon should see. I would love to hear a compelling argument for not using those functions because arrogance is the only reason I can think of. I've been a programmer for 30 years and I've certainly engaged in my fair share of arrogance and been bitten in ass for it many times as well. Putting it in assembler seemed a good idea at the time, but ten years down road the guy stuck supporting it calls me about it and it doesn't seem such a good idea any more.