Sponge: Qualified plugin ID configuration folders

[Minecrell]

SpongePowered/SpongeAPI#1081 changed the recommendation of plugin IDs to qualify them with a group, e.g. net.minecrell.testplugin. This is generally working fine, however when I tested it a bit for while updating the SpongeDocs, I realized this affects several places in our implementations:

• The IDs result in a certain overhead for configuration folders, because now the qualified plugin ID is always used as configuration folder and configuration file name:

We can't simply use the unqualified ID here because there can now be multiple plugins with the same unqualified ID, and if both have configuration files the files would conflict.

Any suggestions how to solve this? Of course we could keep it this way, but it might be a bit annoying to have all the qualified prefixes in the config directory...

• Command aliases are always prefixed with the plugin ID, so if you have conflicting command aliases you always need to type /net.minecrell.testplugin:test. Fixed by adding the unqualified plugin ID as alias additionally, so you can also type /testplugin:test.

[phroa]

I'm a fan of namespacing. I'm not a fan of user-visible Java package namespacing, because nobody understands it and the developers might use a namespace that doesn't include the name of the plugin.

What comes to mind is to add a new "config tag" field to the @DefaultConfig/@ConfigDir annotations. as if that would help at all...

[Minecrell]

@phroa Then there could be easily conflicts with the "config tag". I mean if every plugin chooses the same "config tag" as the unqualified part of the plugin ID (so often a lower case form of the plugin name) and these cause conflicts then we might as well remove the groups from the IDs. We need to find a solution that doesn't easily cause more conflicts.

[Deamon5550]

Could we use the simple ids and only resort to the qualified ids if using the simple id would cause a conflict. Makes the final location indeterminate is the only issue.

[Minecrell]

Well the problem is the following situation: Server has been running with one plugin only for a while, now it is started but a plugin with the same unqualified ID was added. We should probably move the existing folder now. How do we know which plugin the existing config directory belongs to?

[Zidane]

@Minecrell

Sounds like your trying to fix a problem afflicting the 5% but affecting the 95% in the process. Configuration folders need to remain unqualified names otherwise you'll hit the NTFS filename limit pretty quickly for Windows machines.

If the situation above presents itself, that is between the admin and the two plugin developers to sort out themselves.

[Minecrell]

@Zidane If using a qualified plugin ID does not ensure you don't run into conflicts we might as well return to our old convention and continue using unqualified plugin IDs where you directly notice the conflict when starting the server, not when the configurations are loaded. If you say we should not care about the 5%, then one of these options will be probably better:

• Remove qualified plugin IDs again (if they conflict in other ways anyway, why do we need them?)
• Keep qualified plugin IDs for plugin portals like Ore and as recommended convention, but still disallow loading two plugins with the same unqualified plugin ID at runtime. That would basically ensure if you have for example a dependency on another plugin you always target the correct plugin, but it would also ensure you don't run into problems at runtime because these plugins would be disallowed to load at the same time.

I'm personally in favor of the second option because qualified plugin IDs are a good convention IMO and still ensures conflicts are prevented before the plugins start loading.

[Mumfrey]

Configuration folders need to remain unqualified names otherwise you'll hit the NTFS filename limit pretty quickly for Windows machines.

To be honest this is only going to be at the same kind of dir depth as .m2 or .gradle/caches so there should be plenty of headroom unless people are idiots and decide to use ludicrously.long.qualified.name.because.fuck.the.system.ima.gon.use.all.the.packages.mofos.bwhahahahaha.they.told.me.I.couldnt.combine.sheep.dna.with.cheese.sandwiches.and.they.were.wrong

In which case, the user frankly has bigger problems, not least of all running a plugin written by someone who really needs to be put in a room with rubber wallpaper and a comfortable jacket with the sleeves sewn together.

If we're going to recommend fully qualified IDs, we might as well wade right in.

[windy1]

:sheep: :+1:

[windy1]

Possible solution:

• Map the qualified IDs to configs in a file
• Use unqualified ID if no conflict
• Use qualified ID if conflict

E.g.

---> myplugin.conf
---> com/foo/bar/myplugin.conf

com.example.myplugin=myplugin.conf
com.foo.bar.myplugin=com/foo/bar/myplugin.conf

[Mumfrey]

:white_check_mark: more options == more flexibility
:warning: more options == confusing and unnecessary

And on the sabbath day, the Lord Gosling did pronounce _"My children, do not confuse the end user with a metric butload of pointless options. For the user is a fickle and lubricious beast and is easily lead into temptation. Lo! Declare thy standards clearly and stand by them meritoriously and thou shalt discover the promised land, where thy users do not fuck shit up all the time."_

[windy1]

@Mumfrey Hey I love scripture as much as the next Job but I was actually thinking we make this a hidden file.

[Minecrell]

Closing this, considering we have a 4.0 release now this was pretty much decided.

[Zidane]

@Minecrell

I think I want to make one change here.

If the config is shared root then the config file gets the full name.

If the config is under a non shared root then the folder name is the qualified path but the config file is the unqualified ids we did before.

Ex.

Shared:
/config/sponge
--> com.almuradev.backpack.conf

Non-shared:
/config/sponge/com.almura.backpack
--> backpack.conf