Quick plea - feature overlap

Discussion in 'Bukkit Discussion' started by robhol, Jan 2, 2011.

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

    robhol

    Just a quick note about something I feel could be significant.
    (Warning: wall of text-ish. Gist/summary at the bottom.)

    The current selection of hMod plugins includes many extremely versatile ones. An example of this is CraftBook, which provides both Redstone stuff like ICs and programmable controllers, in addition to minecart stuff, and other mechanisms like gates and bridges.

    When plugins try to cover huge areas and do tons of widely varying things, you're almost bound to end up in a situation (sooner or later) where you want one plugin for one of its features but it has other features that conflict with other plugins - plugins on which you or your players may be completely dependent. This situation has been my dilemma lately. I am an admin of a fairly populated server, and have been pushing for a certain plugin to be implemented. However, that plugin and another plugin that already runs on the server are completely incompatible. They do (basically) the same thing, but not in quite the same way. Removing the old one is apparently something my fellow admins are unwilling to do.

    My point is this. Can we please try to make one plugin for one feature? I understand from what I've heard that hMod was more prone to "feature grouping" due to overhead and performance hits associated with more plugins running - Bukkit seems to try to correct this issue, and I'd love for this to be reflected in a more feature-oriented approach for plugins.

    For example, if we take the CraftBook plugin and look at it, it has 3 major features. It provides "integrated circuits" that massively boost Redstone development. It provides large-scale mechanisms like bridges and gates. It also adds some extra control features for mine carts. The way I see it, these 3 features are only "weakly" related, and they could easily have been split into 3 plugins if the framework allowed for that. This would afford server admins a lot more flexibility, since they could pick and mix functionality without worrying about accidental incompatibilities that pop up due to plugins doing - literally - too much at a time.

    In hMod, this could be a pain to update. After all, the more plugins, the more need to update things. However, with Bukkit's built-in plugin update mechanism, this idea looks a lot better here.

    In short: no need for a plugin to provide lots and lots of features. Instead, plugins should be as specialized as possible, focus on one (or very few) things and on doing those well. This minimizes the risk of plugins "precluding" eachother because they do the same thing, and lets the administrator have even more control.

    Does this sound reasonable to anybody else?
     
  2. Offline

    Masau

    Seconded. Since updating will be automated, downloading several smaller plugins (as is the case with iconomy) isn't a big deal anymore. Massive do-everything plugins just make it more difficult for admins who don't want a single plugin to well...do-everything.
     
  3. Offline

    sk89q

    CraftBook shares a lot of code, and that is why splitting CraftBook in particularly is fairly infeasible (and inefficient too). It also makes it easier for me to release one plugin instead of several.

    However, I was fairly aware of this problem, so you can disable any feature in CraftBook that you want.
     
  4. Offline

    robhol

    Yep. I assure you, this wasn't meant as a "dig" at CB but rather a request to those who will be writing future plugins. I only mentioned CB as an example of a plugin with several rather distinct features, and as for overlapping and conflicts, it's my case in point. The other plugin on the server I mentioned is Minecart Mania, which will appparently kill CB on "sight" - something that presumably wouldn't happen if there weren't overlap to begin with.
     
  5. Offline

    sk89q

    It should not kill CB anymore -- only put its dirty fingers into our configuration file!

    Although to be honest, I think CraftBook is truly the only giant plugin :p
     
  6. Offline

    torrentails

    I'd like to see the same thing happening in future too. the plugins that I'm working on have a similar approach: small, flexible, mix-and-matchable, independant but work well together.
     
  7. Offline

    Hamish_G

    I think having a bunch of small plugins would be a little annoying rather than having one blanket one that has all the little ones and then you can disable the little ones that you do not like.
    Much like CraftBook :)
     
  8. Offline

    Masau

    Not if they are auto-updated. If they upadated automatically, then it's only a matter of finding/downloading them the first time (which should be made easier with the repository). Finding the plugins the first time will be easier than disabling everything you don't need/want.
     
  9. Offline

    Hamish_G

    I guess but i still like the "blanket plugins" that cover lots of little things in one.
    Though they may cause lag :eek:
     
  10. Offline

    torrentails

    It's a little hard to say which method will be better in terms of performance and ease of use, it's really up to the plugin developer. I'm just going with small, individual plugins because it's easier for me to manage the seperate projects, especially since I'm still relativley new to plugin programing and java in general.
     
  11. Offline

    Hamish_G

    Yeah, in the end it is up to the developers, they will chose the method that is easiest for them :)
     
  12. Offline

    Isenblade

    still having the option to turn certain features off like CraftBook would be usefull in the do-everything kind of plugins.
     
Thread Status:
Not open for further replies.

Share This Page