CurseForge.com

DataStore

DataStore is the main component of a series of addons that serve as data repositories in game. Their respective purpose is to offer scanning and storing services to other addons.

The advantages of this approach are:

  • data is scanned only once for all client addons (performance gain).
  • data is stored only once for all client addons (memory gain).
  • addon authors can spend more time coding higher level features.
  • each module is an independant addon, and therefore has its own SavedVariables file, meaning that you could clean _Crafts without disturbing _Containers.

Scope : a note to contributing authors

The core of the database is based on my work in Altoholic, and is thus designed with multiple-account support in mind. If client addons want to store data from foreign accounts, the database will be ready for it. Nothing is final at this point though, feel free to contribute, as the concept can and will be perfected.

The scope of each addons is to provide common methods for client addons. For instance, DataStore_Crafts embeds LibPeriodicTable-3.1-Tradeskill allowing it to give more than just scanning & storing data. However, the goal is not to put _everything_ into these addons, they must be seen as an abstraction layer and a service provider, nothing more.

These libraries cannot and should not be embedded, as they all manage their respective SavedVariables.

Existing modules

Each module will exist as a separate addon, so that authors can package only the ones they want with their own project.

More modules will come later.

Information Pages

  • Project overview : A slightly more detailed overview of the scope
  • API : Samples of commonly used methods (work-in-progress)

You must login to post a comment. Don't have an account? Register to get one!

  • 5 comments
  • Avatar of mikk mikk Thu, 08 Oct 2009 12:08:54

    Just a followup: Yes, if people are installing something disembedded, the code would still end up in the addons themselves, but that's nondestructive since standard lib upgrade mechanisms would use the latest code from some newer, embedded copy.

    Last edited on 08 Oct 2009 by mikk
  • Avatar of Thaoky Thaoky Wed, 07 Oct 2009 12:11:03

    Very good idea. It may be a while before I get there due to the time I have to grant to coding these days, but definitely an objective for somewhere between 3.3 and 4.0.

  • Avatar of mikk mikk Fri, 02 Oct 2009 13:29:30

    It strikes me that this is avoidable if the DataStore addons only contain savedvars and no code, and the code is instead embedded as regular libraries.

  • Avatar of Thaoky Thaoky Mon, 28 Sep 2009 14:53:52

    Hey mikk,

    Yup, I know about this, and that's something I want to avoid too. I discussed this with cf admins before launching the projects and that was not possible at that time. I will try to put the subject on the table again to see if there's a chance to make it happen.

    Thanks for you input :)

  • Avatar of mikk mikk Sun, 27 Sep 2009 21:01:14

    Something you might want to take into account:

    If addons package DataStore in their zips, hilarity will ensue when update time rolls around, and people end up installing old DataStores on top of newer versions, just because some addons zips were last generated too long ago.

    This should be theoretically solvable if all such addons live on cf/wowace, and the packager know to update their zips when DataStore changes. It USED to do this for lib changes too back in the day, but that got a bit too crazy.

    Maybe the cf crew could be convinced to add a special type of "external" that is offset from the root zip dir, and causes zip updates when the external changes... hm..

  • 5 comments

Facts

Date created
30 Jul 2009
Category
Last update
16 Nov 2009
Development stage
Release
License
All Rights Reserved
Curse link
DataStore
Reverse relationships
1
Recent files

Authors