It only needs a standard for how to structure the options, how each framework chooses to implement them is arbitrary as long as folks can agree to a standard for the data structure. The recent addition of AceOptions based addons to RockConfig shows that this kind of interoperability is quite possible.
But I hear a lot recently that things are categorically impossible and I think I don't really understand the real reasons for all this, not that I think it helps to understand them.
For practical purposes I do see stuff that I like just plain happen so I'm not too worried really :D
This is really sort of a conceptual question about how libraries plan to handle options and their configuration by the user.
Rock has removed AceOptions and I see that in the Ace3 wiki there is mentioning of AceConsole being split into an AceConsole and an AceConfig part that seems to be comparable to Rock's config part.
Now to give some background: I write small addons for personal use (well I give them away but guess noone uses them anyway ;)) and I have been using Ace2 primarily to give easy option configuration and seemless integration with other addons on the configuration side. (it actually turns out that the fact that AceOptions is gone from Rock is the main difficulty to port my addons to Rock.)
Generally what I like about the Ace2 situation is that in some sense one just defines the the options data structure and one gets slash command and gui integration (Niagara if present) automatically. Other options, like FuBar buttons and dropdown menus can be easily added.
While it may not be perfect it seems to follow a basic "type of data to be configured" vs "representation for that type of data via a cli/gui/..." abstraction and multiple representations can easily be grabbed.
I really liked that and think it's a clean principle. I actually like a commandline interface, not because I want people to use it a lot, but because it provides complementary functionality to other more gui type interfacing via quick changing of often used specific setting (think "/myaddon lock") and the ability to macro script and link to buttons (hence giving a link to Blizzards button gui without extra code).
Rock Wiki states:
Removal of AceOptions support from the Console library.
* It is a major hassle to have multiple implementations for options, as they can sometimes conflict or one can be out of date. There are also issues for some addons only supporting one implementation and some supporting another, causing duplication of code as well as end-user inconsistency.
* Using the console for large configuration is unwieldy. "The poor man's gui".
* Small slash commands are great.
o Sometimes you want to have slash commands, but in such an event, the slash command should be simple enough so that it can be manually coded, therefore input capabilities are still in LibRockConsole-1.0, just simplified from the Ace2 version.
* There is an official gui-based options system called LibRockConfig-1.0
Well in some sense I hope to see options and their representation separated and at least retain the option to provide commandline options as a possible representation. Also I'd like to see this separation because it allows multiple GUI ways to represent the same option set (dropdown, waterfall, some people suggested itemrack-like tab based etc).
Some of the Rock principles noted above are GUI design decisions. It would be good to abstract this for people who have a different GUI design philosophy and hence more flexibility there. Certainly I don't want to write slash command code for all of my addons, and use a separate code (via a library) to create the same option->user mapping via a GUI.
Is it yet specified how Ace3 is going to handle this? Is there an intend to keep a commandline oriented library that implements an interface to an option data structure? How do you feel about option data abstraction and their GUI representation for flexibility?