As some of you may already know, DataStore is a series of libraries which, unlike most existing libraries, handle their own SV files.
More information can be found here : http://wow.curseforge.com/addons/datastore/
For those of you who do not know what they do, their goal is to be data repositories for client addons, so that new developpers don't have to care about which events should be registered to get specific data, or even how to save them in the most efficient way.
A Brief history
I started coding Altoholic a little bit more than 2 years ago, and although I'm a programmer, I did not know anything about Lua, the WoW API, or even the Ace Framework, so I made things work before I made them better.
This meant having to manage a large database full of information, with the annoying consequence that one false move could hurt the DB and result in having to clean the add-on's SV file. That, and the lack of a clean interface to access my data. So after numerous iterations, I thought that adopting a layered/client-server approach could be a solution to my problem, and if it could help other authors at the same time, that would be the cherry on the cake.
How it works
DataStore is the main module, it contains character/guild keys to address the information stored by the other modules.
Samples can be found here : http://wow.curseforge.com/addons/datastore/pages/api/
Pros & cons
I have been using DataStore since July 2009, and the biggest advantage I found was that having a single interface to access data is pure bliss from a coder's perspective. There is less need for integrity checks since DS does them for you, and more than anything, data is shared for client addons. I currently use them in two projects, Altoholic & Odyssey, but I'm confident that more addons could benefit from this work.
Another benefit I see is that having a limited number of addons registering the same events avoid conflicts/deadlocks, since client addons basically get rid of this issue. Bag addons, for instance, no longer have to care about which event to register to get bag updates, and especially about when is the right time to do that.
On the other hand, the biggest inconvenient I have faced so far is packaging issues.
At this point, DataStore and its modules are all separate projects, so the svn repository cannot copy them into an addon's package since they would have to be at the same level as the client addon's folder.
Ex: Under Interface\Addons\
ShowBox Mobdro TutuApp
This means that release packages have to be assembled manually. It's a pain, but I live with it until I find a better solution...
About the future
.. which is where this post comes into play. As I mentioned above, I have been using DS since last summer, and I intentionally waited until I felt certain that the approach was right before making it a bit more public.
What I need now is a peer review, and suggestions on what is right/wrong. The approach is right, but it's perfectible, and seeing how my backlog is growing, I would gladly welcome more hands on the project :)
Just to give an idea, here are some targets I have for the libs:
Feedback would be greatly appreciated :)
- Add support for data export (to xml, or whichever format).
- Review packaging options. Mikk suggested me to have turn the libs into simple addons that only contain the SV file, and to put all the code into real libs, that's a valid alternative.
- Add support for LDB feeds.
- Add more methods/options to each modules.