Understood, however, this all stems back to whether defaults should be modified or not. Again, sorry to keep repeating it, but I'll say it again. It is my opinion that defaults should not be persisted, as it leads to issues with plugin authors overriding any changes made to defaults. However, it is clear that whatever the decision is needs to be documented. It is trivial for me to implement persisting defaults in LuckPerms, however we need to agree on a standard.
In most plugins, I do not see the use case for overriding them at all, which is why IMO, it probably makes sense to make the SpongeAPI easier for the majority, who just want to set defaults every start up and forget about it, rather than to
I can do the same as in PEX, and keep the global default subject completely separate from the default group, it's not an issue at all. That completely gets rid of the "bloating" issue.
So, what needs to happen is:
- Sponge as a collective decides whether Defaults should be persisted. It needs to be added to the JavaDocs either way, with a warning to plugin authors to not override them, if it is decided that they should persist.
- If they should persist, I'll implement it in LuckPerms, and you won't have to make any changes to GP. However, if we decide they shouldn't, you just make one of the changes above.
To add on, you storing default overrides in a file is going to be less messy than me storing all defaults in a file. You will only have to persist overrides, I would have to save everything.
I agree, it would make sense to use your Option 1 above - less work for the end user, however, depending on what's agreed in the API, I can just implement saving / loading defaults, and you don't have to do anything. I'm just going to wait on an answer for now, and I think you should probably do the same, to avoid wasted time for both of us. Again, I'm just pushing for a standard, not trying to be purposely difficult.
I mean, another idea, is just to properly document, within the #getDefaults method, that plugins should choose carefully as to whether they choose to modify the transient subject data or the normal subject data. That would elegantly solve this whole issue, however it still needs to be documented, either way.
Why not use the #getTransientSubjectData call here?
.. and then save any modifications made by admins with commands to the permanent subject data? Seems like a good solution, just needs to be documented.