How can we encourage developers to build plugins based on other plugins?

Discussion in 'General discussion' started by SOFe, Nov 19, 2016.

  1. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    Many plugins actually offer very cool API methods for other plugins to interact with them. A high-quality plugin always provides methods to extend the plugin, not just use a plugin. For example, a good auth plugin always lets people define new password provider, or authentication method, instead of just providing an API to show whether a player is logged in. They always provide API methods that change the behaviour of the plugin from a pretty internal level, rather than just API methods that are almost the same as dispatching commands directly.

    Nevertheless, apart from people writing private plugins (actually some servers want to show their "ability" of developing their own plugins by not using well-known auth plugins), or a very small range of popular plugins (notably economy plugins and ranks plugins), most people prefer to write their own plugin that does the same thing just to add a few new features. This phenomenon is especially notable in auth plugins, where whenever someone thinks of a new authentication method, a new plugin is created (now the mess: SimpleAuth, ServerAuth, HereAuth, JamAuth, and many others that I can't recall...). Actually, many plugins totally do not need to be created, but rather, extending upon an existing, and (usually) well-maintained plugin.

    It appears that most [citation needed] developers are worried that if they depend on a plugin, if the plugin no longer gets maintained, their plugin would get outdated as well since its dependency is outdated. Many [citation needed] are just lazy to study the API of existing plugins.

    I am wishing this thread to discuss about these:
    1. Are there any other (significant or insignificant) reasons that lead to this phenomenon?
    2. Are there solutions that the team, or the community (existing members concerned about this issue), or developers writing popular plugins, can adopt to prevent so many unnecessary duplicated plugins from being created?
     
    ifvictr, applqpak, xBeastMode and 3 others like this.
  2. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    1. I think it's mainly because no-one knows that other plugins have an API that can do that. Also contributing is, that we don't have a place where all plugins are listed, so plugins get created without knowing there is exactly that plugin already existent. And writing, designing and documenting an API is hard, and most devs don't see the use of doing so, so they won't do it. As a result, most devs don't even expect that particular plugin to actually have an API, due to only very high quality plugins do have an API. Also most APIs are only some get() function that don't do much.

    2. We need an unique plugin list, where most plugins should be listed. But that won't really help.

    hz8/ <-[EDIT] WTF how did that get there?
     
    Last edited: Nov 19, 2016
    HittmanA, applqpak and HimbeersaftLP like this.
  3. Sandertv

    Sandertv Zombie Pigman Poggit Reviewer

    Messages:
    786
    GitHub:
    Sandertv
    As I develop plugins too, I have this reason for it; In my eyes it's somehow more fun to code a new plugin, rather than using a plugin and building upon it. It just feels like you've done more to make the plugin.
    The second reason for me is because I don't personally like my plugins to depend on other plugins, because users must download an other plugin to use yours, while maybe not even liking it. It just feels like it's more convenient to make own API methods for easier use of the plugin.
    I do however agree it shouldn't really be like this. For example: Purechat is an awesome plugin, which extends PurePerms in a very good way. Simpleauth + SimpleAuthHelper is another one of these examples. (even though the 2 are both kind of outdated)
    I think those two example plugins are pretty well-known and used a lot.
     
  4. Thunder33345

    Thunder33345 Moderator Staff Member

    Messages:
    2,137
    GitHub:
    Thunder33345
    break down of why they are created: (assumption)
    well for this one it was created originally to counter the flaw of anyone can just login into an op's account
    note: there an extension plugin called SimpleAuth Helper in attempt to extend the function/customizability of simple auth
    originally aim to be a better version of simple auth
    well i would say more of because auth plugin in the existance dont have enough config
    because we can't have an online solution to things
    sometimes people like to make new things,
    sometimes people dislike old things because they arent as good as what they can made.
    and ^ not many people like to hard depend on something making someone forcefully download another plugin unless it is something everyone should have (ex xperm or economy and etc) dosent worth it
    maybe you just cant
    people like to make things, or make IMPROVED things upon older copies of it
     
  5. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    Actually it's because auth plugins need async query support.
    This is not true. HereAuth can support it. Look at my issue on the jamauth repo.
     
    Last edited: Nov 20, 2016
    applqpak likes this.
  6. Jack Noordhuis

    Jack Noordhuis Zombie Pigman Poggit Reviewer

    Messages:
    618
    GitHub:
    JackNoordhuis
    Whilst extending other plugins is a something every developer here should know how to do (if you can extend pocketmine itself enough to make a plugin you should find it pretty easy to extend other plugins' functionality if they have working API's) but people don't seem to do it that often. The main reason for this, in my opinion, would be the lack of people knowing that it is possible to do so (or people are just too lazy to find an existing plugin to extend).

    The other main cause of this may be the fact people dislike or despise dependencies (most of us developers here will more than likely somewhat agree with this). Dependencies are a pain in the neck for multiple reasons:
    1.) Dependencies often have other dependencies — This makes it a pain for the people using the plugins, having to download and configure multiple plugins just to get one plugin to work is no fun and nine times out of ten people complain about plugins being broken because they don't understand why it won't just work by itself. I am also completely aware you could use soft dependencies that rely on configs but you'll always end up with someone not knowing what any of your comments mean.
    2.) We're making plugins for anyone, not just developers — We all need to remember that we're not just writing plugins for ourselves or other developers; we're making plugins for anybody, with most of anybody (in this case at least) being kids or young adults. Your average pocketmine user will most likely not understand what a dependency is so they'll be sitting there scratching their head wondering why someone would be stupid enough to make a plugin that doesn't work or if they have a rough idea of what a dependency is they'd be wondering why someone would be stupid enough to make a plugin that relies solely on another plugin.
    3.) Dependencies lead to more dependencies — If it started becoming the norm to build plugins around other plugins' API methods the chances are someone else will make a plugin that will use your plugins API methods then someone else will make a plugin using that plugins API methods and this can continue on for an infinite amount of times. This is perhaps the most annoying issue when using dependencies in things like plugins, people don't want to install five parent plugins just to get one plugin working.

    Overall there is a lack of plugins making use of other plugins' API methods and it would be good to see some plugins do so as writing good API methods takes time and a lot of thought, but there is a point at which it needs to be limited or we could end up with a plugin repository full off dependency upon dependency.

    This is just my two cents on this thought, so feel free to critique or question anything I've said :)
     
    TheDragonRing, tuff, applqpak and 2 others like this.
  7. falk

    falk Slime Poggit Reviewer

    Messages:
    75
    GitHub:
    falkirks
    Also some people are really awful at maintaining projects. So even if they are updated, you don't have a guarantee that the API is safe. So depending on them isn't safe. I always consider my external API when I build a plugin. And I don't change it. EVER!

    Just to pull an example (not pointing blame at all), I added support for EssentialsPE in SimpleWarp by soft depending it. This was because EssentialsPE started using the same commands as SimpleWarp and this annoyed a lot of users. With my solution, If a user tried to go to an EssentialsPE warp, I would call the relevant method in EssentialsPE. I added this support after I became the official maintainer of EssentialsPE (which lasted a couple weeks), because I thought I would be able to control both projects and force them to support one another.

    @iksaku took EssentialsPE back, and now @SanderTv has it. Both of them pushed the plugin forward and tried to fix API issues that had been present in earlier versions. However, in doing so, they broke the API. They changed method names and failed to make it backwards compatible.

    This puts me in an awful situation. if I want to continue supporting EssentialsPE, I need to check which version is running and call the right method name. That is too much work to maintain. And people are creating issues on my repo, when it's hardly my fault.

    As far as solutions go, if you want your plugin to have an API, you need to make it a priority. You need to make sure it doesn't change and if it does, you provide notice and guides on updating. And if you are willing to do all of this, advertise your API in your README and plugin description. That way other developers can figure out the difference between an API that is intended to be public and one that wasn't built for reuse.

    As a suggestion for Poggit, maybe have a flag like "public-api", which would keep track of plugins that exposed good APIs with some documentation. They could undergo an additional review process.
     
    Last edited: Nov 20, 2016
    TheDragonRing, Awzaw, SOFe and 4 others like this.
  8. Sandertv

    Sandertv Zombie Pigman Poggit Reviewer

    Messages:
    786
    GitHub:
    Sandertv
    I have in fact not changed the API a lot yet, mostly fixed some bugs and added to the update iksaku was planning. Feel free to tell me if you want something different or if I can help you, I'll happily revert any API breaking commit that makes (for example) SimpleWarp not work.
     
    applqpak, HimbeersaftLP and falk like this.
  9. falk

    falk Slime Poggit Reviewer

    Messages:
    75
    GitHub:
    falkirks
    Thanks :)

    I misrepresented that a bit. See https://github.com/Falkirks/SimpleWarp/commit/508e8f06e1f1e8910b06e7973ca20c3a916d4a1e. That is something which didn't need to happen. I have handled it and it's in the past. But at the time there would have been better ways for the change to be made

    That change and the response I had to take, made me lose confidence in the public API. That could have been avoided by adding some backwards compatibility methods or by making a note in the repo about upgrading.

    Again, It doesn't matter much to me at this point. I just want to provide this as an example to other developers of how simple changes to public APIs can mess up things for other developers. And how we can handle that better in future.
     
    applqpak and HimbeersaftLP like this.
  10. xBeastMode

    xBeastMode Shog Chips

    Messages:
    0
    In fact adding an api to a plugin is my favorite thing to do while creating a plugin. I tried implementing an API to my HungerGames plugin where it can easily be extended, and I just called them "scripts". Do you think the plugin has a good enough API to keep maintaining it?https://github.com/InfinityGamers/HungerGames-UPDATED
     
    applqpak and HimbeersaftLP like this.
  11. Thunder33345

    Thunder33345 Moderator Staff Member

    Messages:
    2,137
    GitHub:
    Thunder33345
    hm can't you just do one of these
    oops essentialpe supported API ver miss match
    falling back to dispatching command /epewarp $args
    just hack it away
    OR turn your plugin off OR epe off

    yeah it is pretty tricky problem
     
    applqpak likes this.
  12. falk

    falk Slime Poggit Reviewer

    Messages:
    75
    GitHub:
    falkirks
    Oh oh oh. I wanted to post this somewhere, but couldn't decided where. This thread got me thinking about how I could make my SimpleWarp API more fun to use. And what parts are tricky to understand. I also thought about making a plugin that can be extended and not just used. I decided to make two rather large changes (which broke my internal API a bit).
    1. Save data automagically.
      If another developer sets the destination of a warp, it should be saved just as if a user set it. Previously you would need another line of code to trigger an update, now warps trigger their own updates. Plugin developers shouldn't have to navigate silly internal APIs, if they want to set a warp to public it should be as simple as $api->getWarp("name")->setPublic(). There shouldn't be any need to navigate a data storage system of other internal constructs, let that be invisible. The trade-off for this is that warps have a reference to their manager class, but that isn't too bad in the long run.
    2. Let users attach arbitrary data.
      In order to make sure the SimpleWarp API was usable, I wrote a couple full plugins using it. In both those projects, the part which took the most time was setting up the config. The config was basically mapping some data to a specific warp name. Like maybe a user who owns the warp or a portal trigger coordinate for that warp. So the obvious way to make this easier was moving this data into SimpleWarp. I added metadata to warps, so other plugins can set fields and get them later. This means they can leverage my storage and indexing system. And it makes it easier on the server owner, having all the information about a warp in one config file. See https://github.com/Falkirks/SimpleWarp/wiki/Metadata.
     
  13. Tux

    Tux Silverfish

    Messages:
    16
    GitHub:
    minecrafter
    I'm one to prefer immutable objects with clearly-defined behavior. But that's just me.
     
  14. falk

    falk Slime Poggit Reviewer

    Messages:
    75
    GitHub:
    falkirks
    Fair enough. There are trade-offs for each course of action. But having a setter method implies that it will be "set" properly and in my plugin that means propagating it to a config. The immutability is something else. My objects were never immutable. I have always had setter methods in them, they just didn't modify the underlying data file. So it was kinda halfway between immutable and mutable, and my point is that picking one is important.
     
    HimbeersaftLP and Tux like this.
  15. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    Aren't you both in the LegendOfMCPE team :D
    Actually in my opinion this is the most important. A plugin that truly adds something should not just use the API functions, but fundamentally change how the plugin works. This is what makes a plugin permanently useful, such as an auth plugin allowing syncing accounts with a forum database.
    If your plugin itself is written well enough, you yourself would also be using these functions, so there wouldn't really r a difference between internal and external APIs. What I'm more worried about is that developers can't even understand the API, just like they only know makeWrapPublic("name") but not the method chain you mentioned.
    See also: PocketMine API, the Item->setDamage() with Inventory->setSlot() (clone $item) mess. Developers often don't realize which methods are only modifying the objects and which methods really do propagate the data to the users and the underlying usage (e.g. database, plugin behaviour).
     
    HimbeersaftLP likes this.
  16. falk

    falk Slime Poggit Reviewer

    Messages:
    75
    GitHub:
    falkirks
    Yes, I agree! But I do think there is a difference between internal and external APIs. A good plugin will have a lot of overlap between the two though. There are some functions that change often or are central to the plugin, which are internal API. And sometimes, we create API elements that are only external, like firing events inside a plugin.

    We just share repos on there. Most repos have one of two maintainers, those people decide what is going on with the project. EssentialsPE was always developed by @iksaku (and now @Blabla), it was just hosted with LegendsOfMCPE.
     
    SOFe and HimbeersaftLP like this.
  17. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    I'm currently in the progress of making an extension. The best part is: I can use the DB from the main plugin, by using its API. That is saving me so much time, and others should be aware of such things. I'm also developing a plugin where i try to design an API, i'll see if i can make an API-how to create one? Guide.
     
    Magicode likes this.
  18. Thunder33345

    Thunder33345 Moderator Staff Member

    Messages:
    2,137
    GitHub:
    Thunder33345
    someone should make a thread about how to on resources section so we dont hijack another thread
     
  19. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
  20. Dog2puppy

    Dog2puppy Slime

    Messages:
    94
    GitHub:
    colesquared
    I would implement some APIs into my plugin, but there's no tutorial. D:
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.