"Pure Bukkit Plugin" Concept

Discussion in 'Bukkit Discussion' started by Ribesg, Jan 2, 2014.

Thread Status:
Not open for further replies.
  1. Hi.

    Bukkit is an API designed for third party developpers to be able to interact with Vanilla Minecraft and even add some features to it. One of the best thing with Bukkit is that it tries not to break, as much as possible (well, Mojang do whatever they want). One proof of this is that some plugins created almost 4 years ago still work now. And this is awesome.

    But I think that we lost that. You may have noticed how every update comes with the same comments for every plugin: "When will this be updated for version x.x.x?".

    Server owners are no longer aware of the power of Bukkit. With the "recent" (kind of) raise in the amount of plugins that rely directly on NMS/OBC access, on reflection or on third party libraries like ProtocolLib etc for which updates are necessary, we've seen this more and more.

    That's why I suggest that we introduce a concept of "Pure" plugins, or whatever name you want.
    I am not sure on how it should be given to plugins, but here's my first idea.
    • Plugin authors could ask for their file to be flagged as "pure" when uploading it. With a comment, or with a checkbox if possible. This checkbox would be automagically checked if the previous file was pure.
    • BukkitDev staff would have to do some additional (little) checks that could be integrated in the approval process. Basically checking for import of nms/obc and some other stuff.
    • The file would be then approved only if it is pure. The "pure" (or whatever name) mention should be clear on the file for server owners to see it. It would be nice if the plugin itself was flagged as pure as long as the latest file is pure.
    This thread is here to discuss and get some feedback about this idea. To be honest, I do not really expect this to be implemented. But there is no real cost to launch the idea !
    One last thing: I'm not saying that pure plugins are better than "unpure" plugins. I just want server owners to be aware of what they use.
    At first, I wanted to create a poll, but I prefer to have written answers :)
    JWhy likes this.
  2. Offline


    Here's my poll response: +1 for this idea
  3. Offline


    I agree with the idea, but it could create the misconception that the plugin never needs to update. If the Bukkit API does require plugins to update for any reason, there would be confusion. Granted this does not happen often, but if it did there could be an issue.
  4. It has been stated on IRC that the chances of an official implementation of this are extremely low (aka this will not happen).
    About the possible breaking change in Bukkit, those Pure plugins would have to link an image from an external website. This image could then contain some information after a major Bukkit update, in case of API breakage. This could be a mean to have some kind of global warning to all pure plugin users.

    This image and information content could even be specific per plugin...
  5. Offline


    Just thought I'd chip in and let you know that you can set your project status to "Mature", which signifies that even if the plugin does not seem to be updated recently there is no reason for it not to work with newer versions of CraftBukkit. :)
  6. The API is very stable, however there are breaking changes now and then, so many "core" plugins will have broken up to now. Not sure about "silly hats", but many pvp-related plugins and world generators will be out by now, also "just API" plugins could break with any game mechanics change, any added or changed block, at least in theory.

    I like the idea of flagging plugins as "just API", however there are at least two problems:
    1. It is much more difficult to check for than one might think, though this is not the most critical thing and abuse can be punished and will likely be found on an update. Still this would increase the time spent on the approval process.
    2. Quite some plugins have optional OBC/NMS access, like some of mine. These would still run just by Bukkit-API - would there be a hybrid label? If so, it would further complicate things.

    The approach could however be used for the ticket system as well, e.g. the server could save a file with plugin signatures and similar on each start/reload. Going further into it Bukkit/CraftBukkit could demand any nms/obc containing parts to be included as an extra jar and load those with special class loader, providing the components by the/another service API. That would allow a more strict approval process and easier flagging. However the implementation may be itchy and does not cover reflection (might be done by the class-loaders, though). The idea behind that is to let the plugins fail before the server is actually ready to let players join and not afterwards. Probably i am too much back on topic / off topic, depending on direction of view.
  7. Offline


    I think we should just stick to the "Alpha > Beta > Recommended" system.

    There would be a list of versions (like there is now), and clicking the version will take you to a page with detailed info, like which version(s) it works on, tested on CB version <insert version>, and so fourth.

    Users would be able to contribute information to the dev(s) to help keep plugin information accurate as possible, like if someone tested a 1.5 plugin on a 1.2 server and it somehow still worked, they would be able to submit that information, and if it is correct, then the plugin author will make that change on the detail page of the plugin.

    Just a few suggestions. :3
  8. Well this "Mature" state is really different from what I'm talking about. Also, as you know, server owners are not all that kind of people who actually try to read things and to "read more" than what's actually written. A big clear logo would be better imo.

    Again, the idea of a "pure" Bukkit plugin is more like "it will break only if Bukkit breaks". Some may require minor updates (example: a region protection plugin that protects Minecart. The new Minecart in 1.7 should be added.), but that's not huge random crash due to bad imports or failed reflection.

    It's true that some updates were big enough to break some parts of Bukkit, but on this side, 1.7 is a good example of an update that does not break. I didn't have to update anything in my 8 plugins, but I still have those "when ze update??!!oneoneeleven" people.
  9. Offline


    I have suggested something like this before, but at the time the response was that it would be too much work to maintain. I'm all for it though, as it makes managing your plugins as a server-owner much easier.
  10. Offline


    Or, instead of adding additional work for this to be put into the "dev.bukkit system", just write something among the lines of "shouldn't break among updates as long as bukkit api doesn't change" on top of your project description page yourself?

    Also, additionally, you already can flag previously uploaded files with the versions it is compatible with, after bukkit as released another update.

    So smart users should check for those kind of hints by the plugin author to determine if it is worth testing the plugin out on a newly released version.

    Besides, my guess it that many users will still post "UPDATE!!!", because they are not aware of what "pure" means or simply ignore it, just like they are currently already ignoring the kind of hints I mentioned above and the version information of the files, or asking questions which were answered just a few comments below their own..
  11. Offline


    I like this idea, but I don't see anything wrong with putting something like "this plugin will still work even if bukkit updates" in big, bold print. If people still spam "UPDATE" in the comments, just delete them.

    Maybe, instead of calling them "pure" plugins, what about saying, "doesn't depend on any other API", for the sake of understandability.
  12. Offline


    Too many server owners don't know what an API is.

    Perhaps, and this is a maybe, the community could come together and make a plugin "pure" verification program. If the plugin passes, the author can put a logo/seal on the plugin page.

    Edit: yes, this is the correct usage of too.
  13. Offline


    milesmcc Very true. That sounds like a good idea. I'd support that.
  14. Offline


    Oh no… Oh no! What have you done??? You've given me inspiration…
    Do you know what happens when people give me inspiration? I do work.
    Bionicrm likes this.
  15. Problem: It does not go for all pure-bukkit plugins. Some plugins rely on mechanics or blocks of a certain Minecraft version. In addition there are hybrid-plugins, which might work without nms/obc access, probably with reduced features or reduced performance. And there is one more gray zone with using reflection, to access something that would usually not change amongst MC version updates (e.g. to check which command likely would get executed, while only knowing the typed text).

    For the simplicity of it, it's not a bad idea to detect nms/obc access and to label it, i think.
  16. gdude2002 likes this.
  17. Offline


    I don't think it's a good idea. You could put a plugin like that and think "oh bukkit will never break this". It's what I thought about PlotMe, it uses 0% nms and very little interactions with other optional plugins, but I was wrong because Mojang broke it and we need to use UUIDs now. We never know what the future can bring and other breaking changes like this can happen and will happen. Of course most plugins will still work, but you can't be 100% sure.

    Just my two cents.
    Hoolean likes this.
  18. I totally understand your point. The first idea would be to recognize pure plugins. Sure, some may break, and in some very rare cases like this playerName to UUID migration, most will break. But that's not the question. ALL impure plugins will break (there are a few exceptions) for each update, so there's still a big difference.

    This would not be just "This is a pure plugin". There would be, for example, a "Warning" mode where all the badges/banners on all pure plugins pages would be red, orange or yellow, with a message indicating that there was a breaking change in Bukkit, and clicking the badge would link to appropriate resources on the subject.

    It would also be a global way of handling such problems.
  19. Offline


    I would probably put such a banner on some plugins and just forget about them and not check if they work on new bukkits. They would break and people would have updated their server without knowing.

    We're back to the same problem as before, people will write in the comment that it doesn't work and people will ask for an update, on every plugin with the badge.
  20. Offline


    No plugins are update safe. No one though that Bukkit.getPlayer("String Name"); would get set for removal but it is.
  21. Again, that's an exception. In this case the badge would be changed to something that would warn the user. They don't read anything but a big moving red thing on top of the page is quite visible.
  22. Offline


    So, even though 99% of the time pure Bukkit plugins are update-safe, in extraordinary circumstances (such as the UUID update) they might break, you ‘don't think it's a good idea’. Interesting perspective.
  23. I would not throw too high numbers, what does "99%" mean... stating a duration after which it is most likely that one has to update, would make more sense, in my opinion. Of course orientation can not be "99%" of the plugins, because most servers just don't run 99% of the plugins, e.g. probably 50 % of the servers run WorldGuard, and who-knows-how-many run Orebfuscator or a similar plugin.

    Edit: Probably my examples are not well-chosen for the "pure-bukkit" aspect, though WorldGuard type of plugins can be done so they don't use nms/obc code, WorldEdit can use nms, which is a special case. Often WG still works, but sometimes there are new blocks or entities or Bukkit-events and one needs to update. Don't forget the hybrid plugins, which can run without obc/nms - could be i missed the point of your very post anyway, apologies...

    Many plugins don't need updating with a new Minecraft version, but still a change in Minecraft can kill a plugin, or force it to be updated - necessary configuration changes could also be counted as "updating", though that may be discussable, still one might have to 100% know-it-all, or look it up on the plugin page and apply the alterations, e.g. add new ore-blocks to xray-stats. Then you have changes like UUID, which are rather seldom but count in too.
  24. Offline


    I'm g and I approve this message.

    Sorry for necroing; there are arguments for and against this idea, but I'm going to place myself strongly in the "for" group.
  25. So I finally implemented this.
    Here's what it looks like:
    BukkitDev / Curse

    Both plugin name and author name sizes can be customized to fit, for example NEnchantingEgg doesn't fit with the default size. See: BukkitDev / Curse

    And finally here's what it looks like if not on a valid / whitelisted page:

    Whitelist available on http://pure.ribe.sg/
    gdude2002 likes this.
Thread Status:
Not open for further replies.

Share This Page