You are basically describing a framework, toadkiller, and this isn't universal because of the same reasons multiple frameworks exist; Different goals, ideas and assumptions as to how it should work.
These elements are tied up and need each other in order to work, that's why they can't be standalone libraries.
That is true for the CLI & GUI, but the base lib just provides data and persistence for the data. For some mods that is sufficient & all they need. Mods that need preferences add either or both the CLI or GUI. I like ckknight's suggestion of having a common way of accesing things so another lib that traverses the options table & handles updates & refreshes etc. makes sense. This lib can maintain its own browsing state so the CLI & GUI open to the same spot when invoked (which fixes a pet peeve of mine which is the boring redrilling down to where I was & am most likely wanting to be).
Also note that while I suggest a single CLI & GUI, obviously a variety of ones can be built. However that would make extensions dificult. So perhaps a reference GUI is a better way to think about it. Compatible GUI's thus need to also be compatible with the extension mechanism.
So yes, it is a 1-3 library "framework", but I think it can be done to be capital F Framework agnostic. Also absolutely any mod at all could use it or just 1 or 2 parts of it. Now it is true that to do the CLI or GUI part you could & probably would use some specific framework but from a user & author's point of view the point is that your data get's saved & users can mess with the data they need to mess with & the author wrote very little code to do that. Also, unlike Ace b4 it it can become a standard across all mods willing to use LibStub. Additionally if it is extensible then the core can remain simple & unclutered & individual mods can add all the bloated goodness they need themselves.
Quote from ckknight »
...The only problem that remains (that I honestly don't know how to solve) is that then things wouldn't necessarily be consistent from the user's point of view.
I don't get why that would happen? Do you mean that a particular data type may not show up in some version if it cannot edit it as Halgrimm mentions? Or that the CLI & GUI should present different views on the data?
Certainly for where AutoBar is going not all things are going to be possible in the CLI, or certainly not in a nice human usable way, although perhaps in ways acceptable for scripting purposes. As long as the GUI can handle everything required it should all work out fine...
You know what, I am going to 2nd that motion. I too would like to see a framework independant:
1) DB library. This would have a common format that any mod whatsoever can use. It has absolutely no GUI or CLI or anything. Just persistence & defaults. Ideally it would also support some kind of inheritance down its hierarchy so I could as an example have
So a particular option set on MyModDB would be global to all, but overideable down the line. So for instance button size could be set on the mod level & thus all buttons are same size unless a particlar bar or button has it set as well. A call for button size to a particular button would ask the bar for the size if the button doesnt have it etc.
2) GUI Library. Given the DB library & a layout description (like aceoptions table), provide a GUI for manipulating it.
3) CLI Library. Same thing but with a CLI for manipulating it.
Now CLI can & should probably only have 1 implementation.
We know GUI already has many but I would like to vote for perhaps a fatGUI & a thinGUI. thin would handle only simple data types which suffices for a lot of mods. fat would be kitchen sink & handle mods with complex needs.
Alternatively there could be a plugin scheme to a thin GUI that makes it extensible. For example the type dispatcher & object factory could be changed to be table driven. A "plugin" then simply adds a new type to the various tables, provides any parameter parsing needed beyond the basic ones provided, its factory method etc.