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

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

  1. aliuly

    aliuly Silverfish

    Messages:
    23
    GitHub:
    alejandroliu
    My main issue with plugins depending on other plugins is around dependency issues. In general, it is easier for people to just download one plugin and be done with it. Since we don't have a Plugin Manager that solve dependencies.
    Then after that, you get the issues with the updates (as Falk mentions), ie changes into plugins can make life a bit complicated.

    I myself have a little experience with plugins and have wrote a couple. Since I don't like to write the same things multiple times I keep all my common code into a little library (libcommon) that can be packaged as a plugin or embedded into a plugin. So when I release a plugin I can have a version that will use the libcommon plugin, or a version that has everything self contained.

    So yes, the version that has everything self contained is bigger, but storage is quite cheap now, so that is hardly a problem.
     
    Jack Noordhuis likes this.
  2. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    I originally started this thread to discuss about cases where you should create plugins like "extensions" for other plugins so that not the whole plugin has to be created, e.g. if you want forums account support for auth, you create a plugin adding a DataProvider to SimpleAuth, not to create another auth plugin. Seems like the topic gets shifted to talking about less relevant plugins?
     
    Thunder33345 likes this.
  3. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    Working on it :)
     
  4. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    Not really feeling the topic has shifted too far
     
  5. aliuly

    aliuly Silverfish

    Messages:
    23
    GitHub:
    alejandroliu
    Another way to implement APIs without going into dependency hells is to use something like Android's intent system.

    Let's take an Economy API as an example. You define an Interface to it. Then you would register the interface to the server. So when a plugin comes along and wants to call the API, they would look-up the interface and send it to it.
    If multiple plugins implement the same interface, the server owner can then choose which interface to use.

    This solves the dependency hell because you could have the Economy API in a standalone Economy plugin, or have a Rank plugin that also has its embedded economy API. The server owner then chooses which interface to use.
     
    Primus and SOFe like this.
  6. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    I have also heard that there is something called Vault in MCPC. It just allows dependency on one plugin that has soft dependency on many other plugins, so you just need to look at the API of one plugin.

    (How come this discussion is getting further and further from what I was talking about? I was just talking about depending on a single plugin!)
     
    falk likes this.
  7. falk

    falk Slime Poggit Reviewer

    Messages:
    75
    GitHub:
    falkirks
    LegendsOfMCPE tried to remake Vault, but we didn't get very far. https://github.com/LegendOfMCPE/Vault
     
  8. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    Interesting.
    Any thoughts on continuing that project?
     
  9. Sandertv

    Sandertv Zombie Pigman Poggit Reviewer

    Messages:
    786
    GitHub:
    Sandertv
    There's really not a lot of members of LegendsOfMCPE still actively coding pocketmine plugins, so I'm not sure if the magic is ever going to happen.
     
  10. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    Magic is always to happen. Also, everyone can just clone that project and continue it.
     
    korado531m7 likes this.
  11. Dog2puppy

    Dog2puppy Slime

    Messages:
    94
    GitHub:
    colesquared
    But when everyone clones, it, it all splits apart.
     
    SOFe likes this.
  12. Jack Noordhuis

    Jack Noordhuis Zombie Pigman Poggit Reviewer

    Messages:
    618
    GitHub:
    JackNoordhuis
    Almost like every thread on this forum splits apart and ends up on another completely irrelevant subject.
     
    dktapps and falk like this.
  13. Dog2puppy

    Dog2puppy Slime

    Messages:
    94
    GitHub:
    colesquared
    lol. One thread might have started talking about MobAIs, and then it morphs into something else that's completely unrelated.
     
  14. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    Vault is purely an API standard. It will be terribly meaningless if we have tens of standards once again.
     
    Sandertv likes this.
  15. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    Not again! I hate multiple 'standards' we need one fucking standard and not 100. So let's develop a new one! ~~10months later~~ we have 101 standards.
     
    dktapps and SOFe like this.
  16. Thunder33345

    Thunder33345 Moderator Staff Member

    Messages:
    2,137
    GitHub:
    Thunder33345
    wait for someone to link for the XKCD
    and that is how spoons came to be

    5 competing standards = someone want to make a centralized standard
    next month = 6 competing standards
     
  17. HimbeersaftLP

    HimbeersaftLP Fish

    Messages:
    2,401
    GitHub:
    HimbeersaftLP
    Here we go: xD
    [​IMG]
     
    SOFe, falk and Sandertv like this.
  18. robske_110 (Tim)

    robske_110 (Tim) Wither Skeleton Poggit Reviewer

    Messages:
    1,342
    GitHub:
    robske110
    Overunderengineering FTW
     
  19. Magicode

    Magicode Baby Zombie

    Messages:
    183
    GitHub:
    magicode1
    I really like that idea! An API Tutorial would be super useful!
     
    Last edited: Dec 10, 2016
  20. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    This is harder than teaching people how to write plugins. A well-organized plugin always has its interface and implementation layers well-separated. I'm not talking about the pointless creation of interfaces like CommandMap in PocketMine - you don't need to create an interface for every class. My point is that if your code is written well, every method that you call in your commands should be something that can be used by all other plugins. For example, the Player->sendMessage() method in PocketMine was originally only for internal use, but it becomes the most popular API method used by plugins. It is because :shoghi: properly organized the code such that you just call a simple function to send a message rather than creating a packet and sending it every time. In this way, people can understand what you are doing easily just by looking a small amount of code. This also reflects that having extremely big functions is bad as the code is barely readable - if you need to put comments in front of a block/group of code to show what you are trying to do within a function, you should probably separate that block/group into a function. Such separation of functions will eventually turn into API functions, which can be utilized by other plugins as an API.

    In addition, every time you ask yourself "Should I do something else here?", you should allow other plugins to do something there with the relevant data; for example, call a custom event or like the RegistrationStep in HereAuth or like the DataProvider in many plugins that support multiple types of databases.

    Before you release a plugin, look at all private class properties. Are there any private class properties that should be exposed to or even editable for other plugins but is not possible yet? And, check if all your public functions do what they seem to do - for example, if you have an API method called setTeam(Team), does it really set the team or the player? Or does it only change the local data reference without modifying the data, which other plugins will try to use and find out that they aren't changing anything useful?

    (Oops, I think I already created the thread you were talking about!)
     

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.