This file is for brain-dumping.

Separation of client and menu:
	Let's keep them mostly separated. I was thinking of keeping the config menu in menu environment, so we won't have to clutter the client-state with commands. Or maybe full menu in menu env. and a smaller menu (think context menu) for client.
	The full menu wouldn't change the values directly. Modifying the values does nothing until you press the Apply/Save/whatever button, which then saves the config to a file. With some state magic, we could also make it trigger a hook in client-state, if it exists. The client would then reload the config-file and apply the new config. Maybe the client-side context menu could change the values directly, without need to save? Quicker tweaking than going to full menu that way.

Config:
	YAML with yaml-cpp. A lua-wrapper for the config files, Lua-side shouldn't need the full YAML library.

	Links: http://en.wikipedia.org/wiki/YAML, http://code.google.com/p/yaml-cpp/

Lua folder structure:
	I've been thinking this a bit. The current way I'm leaning towards takes some ideas from GMod and WoW addon structure.
	Basically we'd have data/, core/, menu/ and addons/ under iris/. Data would contain user-data files, logs and the like. Probably config too. Core and menu would contain the files that are ran when iris loads the first time. Menu is loaded immediately when iris is required, and contains basic menu and configuration stuff, meant for the configuration menu. Core is loaded right before enum/ and would contain the basic libraries for injection. Both of these would contain a init.lua that would manually load the files, one-by-one so we don't have to do that goddamn alphabetic ordering (bleh).
	Addons. Every addon has its own folder, and inside it is a YAML document, like info.txt. That would contain info like author, version, name, description and !!!dependencies and files to include!!!. This is the WoW-part of the addon system. When the addon is loaded, info.txt is read and iris loads the Lua files in the order indicated by the info. Dependencies are used if the addon depends on another addon (not core), and is used by iris to determine addon load order. I still have to figure out an algorithm for this.
	The tricky part in addons is configuration, since configuration menu obviously needs to hold addon settings as well. So should we just load the addons normally in the menu state as well? This might work, since the addon structure I'm thinking depends mostly on hooks. Loading from menu should be as simple as loading the addon and not calling the game-critical functions. Addons could have a hook like BuildMenu where they could manually construct the needed vgui stuff for settings (like in Hades).
	More addon config. Should each addon have their own YAML config file? Should they all share a big one instead? I'm considering having one config file per addon, stored under data/config (or maybe just cfg/ or config/). data/config most likely, since data/ is meant for user-data, but cfg/ or config/ could be used for core config files, like function signatures and stuff.

	After-thoughts: Instead of init.lua in core/ and menu/, we could just have a YAML document like info.txt (init.txt?) that specifies the load order. This way we wouldn't even need an include function in Lua.
	Shared libraries between core and menu? No idea. Maybe they want to share some vgui wrappers, but how? Should menu/core just require them from the other somehow? Dependencies? Copy-paste the files?
