Suggestion about updater and metrics in plugins.

I think any plugin file should be rejected and removed if the plugin does update check or metrics on server main thread.

 

It's the BukkitDev staff's job to ensure that plugins do not contain malicious code. We do not have the time to review every plugin for quality purposes. If you're interested in ensuring that such things are properly threaded, you should encourage the developers to use one of the open-source projects available that are. However, making the staff do it isn't possible as they won't reject for plugin quality - that would cause all kinds of chaos, and extend the approval time greatly. This of course ignores all of the debate that would be needed over whether this is even a valid thing to reject for.

The bottom line is this won't happen.

 

You can't force someone to use updater or metrics in a plugin. Besides, there is already tons of plugins without them.

 

He's not insisting that people use them, just that if they do that they should adhere to a set of standards. The idea makes sense, but it's something only the community can enforce.

 

Because metrict or updater on main thread freezed or crashed my server more times than anything else.
I got tired of decompiling every plugin that i wan't to install just to check if it is not doing update check or metrics on main thread.

Well, looks like i will have to write an injector that will deny any connection to metrics and dbo to fix that

 

Why should i check if plugin contains metrics or updater?

Well, at least there should be a rule like your plugin can be removed if metrics or update found on main thread, so we can report plugin that does this.

 

They are don't listening , most of them are just like - "that's a 0.1% chance so i won't change it, also i don't know what is thread, so f*ck off" or 'my server never crashed, so this is no possible' or 'i tried to force update check 30 times, it didn't crash so f*ck off'

I already disabled metrics, but autoupdaters are my headache now.

 

They usually run when admin joins(that's not my issue, i don't have admin permissions specially for this case), and at some interval(and this is where shit happens).


Well, ok, i will just write an url injector or class visitor that will inspect plugin and check if it connects to mcstats or dbo and warn me. Myabe i will even add this to autosaveworld.

Close the thread.

 

All plugins that have an auto-updater have a toggle in the config to disable it. This is one of the rules. Most new plugins using the latest version of Gravity's updater can even have their updater disabled through the config file under /plugins/Updater/config.yml - I suggest you check if that exists in your case.

 

I can only agree with these words.

Because update-checking and any other network activity may add lags and freezes to the server (if this method is not runs asynchronously). Server owner will not be able to find a reason of this lags without lucky-disabling the update checking.

And plugin developer, if he was not informed about this lags, will not be able to solve this problem.

I don't remember who - but I think he was a great guy for BukkitDev Staff - informed me about this issue with my update checker. And I think it's a good idea to inform every plugin developer about possible reasons of lags. It will made all plugins better

I'm happy that not all BukkitDev staff think like you
I obtained really good advice during the approval process of my plugins. Thanks to the BukkitDev team for help

 

I must concur with Gravity's comments.

Firstly, my plugin files took 2 days to approve, and I would not want that to be stretched out any further.
More importantly, however, I don't believe that the file approval process is the right place for quality control. If we mandate that network operations happen in a separate thread as part of mandatory quality control, it's only a small step before we enforce all manner of other things: Should file read/writes be forced to happen asynchronously? What about networking operations? SQL calls? Perhaps we should enforce that Java Exceptions must all be handled and never shown to the player?

I for one certainly do not want to have to engage in a lengthy discussion explaining that ‘no, the reason my file read/writes are happening synchronously is to avoid thread deadlock and data corruption’ every time I try to upload a new file.

(I realize this may be considered an example of the ‘slippery slope’ logical fallacy, but I believe my point still stands – if we make BukkitDev about quality control, where do we draw the line?)

 

pokepal101
I understood you. But if you continue to go to extremes you can suggest to skip approval process. Why not? It will reduce approval waiting to 0 seconds

Now, during approval, our project could be rejected according to:
1. Update checker is not using BukkitDev API
2. Users are not informed about update checker in plugin description
3. Plugin did not use update checker
4. API key included into project
5. etc.

Why not to add to this list an requirement to create update checker that not harm the server, not freeze the server, not adding lags to the server?

Some time ago there was a problem with BukkitDev (I don't know what happend, may it was BukkitDev problem or may be it was ISP problem. But there was a problem to access to dev.bukkit.org). After restarting server was totally freezed. Without any messages in server log. After sometime we found the reason. It was few plugins that tried to find updated versions.

P.S. I suggested before, but it was declined: to build-in Metrics analog and update checker into bukkit API. I still think that it's a good idea to provide lag-free update checker to developers than wait when everyone will learn how to code his own update-checking class.

 

fromgate because it sets a precedence that we will offer those services to everyone and for anyone quality reason. For instance, "this plugin didn't set up its permissions correctly, why is it on BukkitDev?" - you could make the exact same "confusion" argument to try and justify the staff rejecting plugins for such thing. You could see how testing the quality of the plugins would become impossible.

We do not reject files for "Plugin did not use update checker" or "API key included into project" -- the things we DO reject for are for security, not for convenience or quality assurance. Those are not our job. If you would like to make a project that independently reviews plugins to fit your criteria, please feel free. But don't try to force the staff to do spend more time on the queue doing something that they shouldn't have to be doing.

This isn't going to happen. Again, bottom line.

I'm locking this thread because of the above statement. I hate to seem like a dictator, but I am emphasizing a very fine line between what is and what is not the responsibility of the BukkitDev staff. If you'd like to suggest a change to the guidelines regarding security, I'm happy to consider it. I will not, however, entertain those that turn the staff into a quality assurance team.