Add Asynchronous restriction to Update Checkers

Currently, plugins are allowed to use updater services which lock the startup process due to waiting for server responses from BukkitDev. I feel that this is a problem for servers, and the guidelines/restrictions for allowing plugins to use the updater service should include the stipulation that the updater service should be run Asynchronously. This prevents server owners from freaking out when/if there is a service interruption to DBO, or for some reason their server has blocked the HTTP request.

Without this it can be a pain to update all of the plugin configurations that do have autoupdating just to get the server to stop from locking up at startup. Once the service interruption has been corrected it creates a lot of work to just have to go back through and re-enabled the autoupdate feature in the future if it was desired.

 

The BukkitDev Reviewers don't check for code cleanliness or skill, they check to make sure it's safe. Unfortunately, this doesn't fall under that umbrella.

 

I would argue that not using an asynchronous task for web-related checks constitutes unsafe as it completely locks up the server and gives the owner the impression that their server is malfunctioning, or possibly even has hardware issues. Not imposing this restriction validates carelessness, and reckless behavior on developer's part and is borderline Malicious.

 

This is true of many things a plugin can do. Poor programming in almost any plugin can cause significant hardship on a server giving the same impression of a server malfunctioning. We simply do not have the manpower to start taking on QA tasks and must stay strictly checking for malicious behavior in plugins, and avoid denying for poor programming practices.

 

http://forums.bukkit.org/threads/suggestion-about-updater-and-metrics-in-plugins.206047/

See my posts.

 

How about a change to the guidelines then that explicitly states you shouldn't be doing it in a non-threaded manner, not necessarily denying plugins. At least notifying plugin developers of how they should be implementing the Updater can go a long way to preventing this. The current doc doesn't really do this, and links to third party sources give a very specific implementation that says it needs to be changed. This isn't really good enough as it is incomplete.

On another note BukkitDev is a curse site, and I feel like stating you don't strive for quality in submissions is kind of counter productive to the product . You're already doing code reviews, where is the line drawn for what constitutes malicious carlessness? When you're doing a code review of the classes it's not hard to see if the check is done in a threaded manner or not in a way that will explicitly cause problems if the DBO site is having a disruption in service. You're already forcing checks to the DBO servers (if people want to include them) for quality assurance, it should be a requirement that the plugin also not lock up if the DBO servers are also under maintenance.

I understand you guys aren't wanting to do quality checks on plugins, but I feel that submissions that base their operation on the uptime of a curse service should require an addition quality pass-through as they are also reliant on a curse service.

 

Guideline changes require enforcement by the staff. Changing a guideline without enforcing it is like not changing the guidelines.

These requirements are not for quality, they are for security. Nowhere have we made the claim that they are anything but. There's a very fine line between checking for quality and for security, and we are not going to be crossing over into the former.

 

Oh well, I feel like this is a mistake and not even giving a list of recommendations seems pretty bad.. But you guys aren't open to it. Hopefully you'll come around eventually.

 

There is no reason you couldn't create a thread in the Plugin Development forum or the Resources section to help those who want to implement an updater in an quality way you suggest.

 

If the plugin developer was incapable of implementing auto updating asynchronously (or implementing it at all as I absolutely hate plugins that auto update), I highly doubt the plugin is worth using. It likely is filled with bugs, flaws, and performance issues.

Worst case scenario you pull (or decompile) the code and rewrite it. Perhaps server owners (non-developers) are incapable of doing this, but I don't think their standards should be that high anyway.

EDIT: Now what should be a requirement is uploading source code! Plugins that don't upload source code are truly a pain.

 

I beg to differ. Just because a plugin author doesn't understand the need for it to be aync does not mean they are a subpar programmer and that their work is not worth using. I personally made the mistake of doing this a bit ago, and I have tested all other parts of the plugin. Don't judge a book by its cover.

 

would something like this receive a sticky? or get included into submission guidelines? At this point unless someone with a Bukkit tag states it I don't think it will actually be listened to.

 

This is like saying (in regards to threading and thread safety) calling non-thread-safe Bukkit API calls from an asynchronous thread does not mean you are an inexperienced programmer. The former shows that the plugin was indeed created by an inexperienced programmer, and it is not incorrect to assume that the programmer has also made other mistakes in their code that may attribute towards bad performance or other failures.

Being inexperienced is the only acceptable excuse for making a mistake like this, and I will not give people a hard time for it, but I do believe that they need to learn forward, admit their mistakes, and correct them.

 

For what it is worth, I agree with the decision that BukkitDev staff shouldn't be trawling for plugins running auto-updates in the main thread, but I definitely think that this deserves a stickied thread in the Plugin Development forum, or an inclusion in mbaxter's "Common Mistakes" list.

 

mbaxter - thoughts on adding a section about this?

As an addition, I've seen this issue with mcstats.org pushing so a mention on that would also be appreciated to not run them on main-thread (though less likely to happen since v3).

- Thanks

 

Codex Arcanum Sleaker I thought I had that in there. I'll add it this week (remind me if I don't, I'm unavailable until Monday).

 

as long as plugin developers allowed to include netIO features and set them ON by default situation wont change.

with all netIO turned OFF by default issue will be terminated.

unlike sync\async usage checking default configuration easy and fast.

 

mbaxter Reminder

 

I said remind me if I don't

 

Oh, derp. Did a quick skim over the common mistakes post, and somehow missed the new entry. My bad.