My software has already been updated with a Plugin Page which looks almost exactly what headkaze's "Plugin Manager" look like.
The user selects a plugin from the list and clicks the "Configure" button. This will cause the jukebox software to call the "Juke_Configure()" routine for that particular plugin. The code inside the "Juke_Configure()" routine (written by the plugin author) would be in charge of opening up a plugin specific configuration application window (exactly like Headkaze's example shows). The user of the jukebox software can now configure the plugin exactly how they would like it to be configured. When all configuration has been completed and the plugin configuration application window is closed I would expect the plugin to store all the configuration settings to some file which the plugin maintains itself.
Note: When the jukebox software starts up, there is no reason to automatically call a plugin configuration routine at all ie: no need to call "Juke_Configure()" at all during startup). The user can simply go into the plugin manager page and click the configure button for the plugin they want to configure. The user can actually configure the plugin many times over and over if they forgot stuff or want to change settings. There is no need to limit the "Juke_Configure()" routine of a plugin to only be called one time.
Now, with this description of how a plugin should be configured stated above, I do not see a need for any plugin to "store" any command sent from the jukebox.
This is how I would expect the procesing of a "coin insert" event to occur:
1) User starts the jukebox software up
2) User goes to the plugin manager page (within the jukebox software) and sees their plugin listed, highlights their plugin and clicks the "Configure" button to bring up the plugin configuration window.
3) In the plugin configuration application window, there is a section where the user can select which sound they want to hear when a "COIN_INSERT" command is received. The user simply chooses a sound and then saves the configuration, then closes the configuration window which will take them back to the jukebox plugin manager page once again.
4) While in the plugin manager page the user clicks the little checkbox next to the plugin name to enable it (ie: so it can receive command indications) and then exists the plugin manager page to return to the main jukebox application.
5) User then wants to buy a song so they put a coin in the slot of their machine which makes the jukebox software send a Juke_PluginCommand("JUKE_COIN_INSERT", cmdvalueText) to the enabled plugin application.
6) The plugin will determine the type of command is a "JUKE_COIN_INSERT" command and will then look up in it's own configuration file what exact sound should be played when a coin insert command is received and then will play the sound.
That is exactly how I see it working ...... still no need for the plugin to "remember" what command is being sent because it is sent the command directly everytime. Now, the plugin obviously has to offer a way for a user to indicate what sound should be played when a JUKE_COIN_INSERT command is received, but that is all up to the plugin application to figure out how to do that and how to save the information for look up later.
Based on this example above I still see no need at all for a complete list of commands to be sent from the jukebox into the plugin for storage. The plugin author should know what exact commands can be sent from the jukebox software to the plugin by simply reading the plugin SDK documentation. Once the plugin author knows which commands are valid to be received, then the actual plugin application can be created to offer the user settings for each of these commands which will define exactly what should happen when the command is received by the plugin. But again, this is up to the plugin author to code the application and store all the mappings for each command ..... the jukebox software should not have to worry about any of this. Again, no command list of any kind is required to be stored by the plugin.
** Now ..... perhaps you wanted the plugin application to be "automatically" updated somehow when new "commands" are added to the SDK and somehow have the plugin application understand that a new command exists now without the plugin author having to update their plugin application manually everytime a new command was defined in the SDK? Is this what you were trying to do? I personally would not know how to do something like this but it might explain why you wanted the plugin application to know about all existing commands. Perhaps ..... this is just a guess obviously.
PS: Thanks headkaze for providing the Plugin Manager pics