[Misc] APIHandler 0.3 - Connecting Plugins :3 [522]

Discussion in 'WIP and Development Status' started by Isabaellchen, Mar 6, 2011.

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


    <Edit by Moderator: Redacted mediafire url> ● <Edit by Moderator: Redacted mediafire url> ● <Edit by Moderator: Redacted mediafire url>

    As discussed on this thread: <Edit by Moderator: Redacted mediafire url> Many Things Doing Same Damn Thing[/URL] too many plugins do the same while they all have unique structures.
    This results in huge overhead for developers as every plugin has to be compatible with each other.

    Me and others came to the solution that it would be wise to have one Interface that is shared by the plugins so plugin developers can refer to that interface no matter what plugin is using that interface.

    The Catch is:
    Who is defining the standards?
    The Answer:
    We all together do this.

    To get things started, i made the APIHandler, to which i all invite you to contribute.
    (the best thing is, it doesnt use permissions or is waiting for persistence *cough*)


    How To Use It?

    Here is small diagram to show the basic structure.
    Its no UML as i wanted to keep it as simple as Possible:
    Lets take currency as an Example.

    First of all, in both of the following cases you need to add the APIHandler.jar to the libraries like you did with the bukkit jar-file.

    1. If you want to use a currency for your Plugin that requires a Currency plugin,
    you add a field:

    public static CurrencyAPI currency;​

    and create a method like the one below, that you call on the onEnable()-method of your plugin:

    public void loadAPIs() {​
    APIHandler handler = (APIHandler) this.getServer().getPluginManager().getPlugin("APIHandler");​
    try {​
    currency = handler.getCurrencyAPI();​
    } catch (NoCurrencyPluginException ex) {​
    Logger.getLogger(MyPlugin.class.getName()).log(Level.SEVERE, null, ex);​

    2. If you want to create a Currency plugin others can use,
    you edit the class definition of your Plugin like:

    public class MyPlugin extends JavaPlugin implements CurrencyInterface {​

    And implement all the methods from the interface.


    What can i do?

    The most important thing is discussing stuff, and finding out what is the best solution to fit the requirements for such a Handler.
    Currently i only implemented the CurrencyInterface as it only has two mehtods in its current version (balance and transfer).
    You can read about the most important thing, the interfaces, on the <Edit by Moderator: Redacted mediafire url>
    Feel free to add new Interfaces there.
    But still there are some quirks like setting a Interface to exclusive or not.
    The current system works with an observer pattern, where all the hosting plugins are registered to, and when the client calls a method, each plugins method gets called.
    I really cant decide if there should even be support for multiple plugins of the same type.
    Which is why i created a wiki, so we can easily edit stuff that comes to out minds as this can be discussed in theory.
    Still if you want to go on working on the sourcecode i will just give you access to the git repository.



    Feel free to ask here, write on the wiki or mail me directly.

    This is a community project...
    --- merged: Mar 7, 2011 5:08 PM ---
    Renamed the jarfile to aaaAPIHandler.jar so it gets loaded as the first plugin, classes and packages stay the same. (Crosses fingers for the devs to implement a lib folder)
    Made the plugins register when an API gets requested, not when the APIHandler is loaded by the plugin Manager (Would result in empty APIs)​
    Last edited by a moderator: Jul 14, 2017
  2. Offline


    Cool, does your plugin registration work consistently?

    If the other plugin is enabled before your one, getPlugin("Name") returns null.
    Your system handles the interfaces centrally. Have you considered allowing authors to extend them at will.
    Also, it might be worth having a recommended and actual page for each interface.
  3. Offline


    I like it. But real problem would be convincing everyone to use it.
  4. Offline


    Plugin Devs will love it, because they won't have to mess with new versions of required plugins anymore.
    Users will love it too, because they can choose from a variety of implementing base plugins. So this is a Win-Win situation:D

    Thanks, isabellchen!
  5. Offline


    Yeah well this is a problem i can ponly solve by calling the API handler aaaAPIHandler to make sure it gets loaded first. WOuld be nice if bukkit had a lib folder but the devs dont seem to want it.

    What do you mean? Implement their own interfaces? That would totally break the intention of the APIHandler to have a unified structure... (if i got you right)
    What kind of page are you talking about? A wiki page?
    Renamed the jarfile to aaaAPIHandler so it is the first plugin that gets loaded, maybe im going to make a aaaMySQLDriver plugin so people can use mysql without making a fat jar all the time :rolleyes:
  6. Offline


    I am thinking that they implement an interface that extends the standard one. It would provide all the standard methods, but also could have additional ones. At the moment, adding new methods requires an update to the central API.

    The idea would be that they would add their methods to the central wiki but could implement them immediately.

    Yeah, on the wiki, I was thinking that you could have a page which shows the current state of the API (as per the last load) and also another linked page that people can edit. The 2nd page would allow people edit to add requested API methods.
  7. Offline


    Maybe a merge of this APIHandler and my UniversalStandardAdapter. Both are following the same purposes. APIHandler has a nice GenericAPI class and my plugin would allow to register any interface.


    PS: I haven't released USA yet, because I want a solid base where the default adapters (permissions/economy…) could base on.
  8. Offline


    Just another wrapper for things that already do the things you are doing. Great.
    Next we'll see APIAPIHandler
  9. Offline


    to Raphfrk and xZise
    Any Custom interface would totally break the idea of this APIHandler.
    If there is a need for a certain Method, that should be shared by all the Currency plugins, it should be defined as a standard method and thus included into the CurrencyInterface.
    But if one plugin uses its own interface someone would be able to use methods that only one Plugin uses and result in the same situation we have at the moment....
  10. Offline


    Okay it is a good point, but it won't break the idea. Because breaking the api is possible without or with an APIHandler.

    But one point I miss in your plugin, is it doesn't handle plugins which are not enabled. For example if I disable the permission plugin on my server, the users of this plugin never get informed, that the plugin isn't available.

  11. Offline


    Then you most obviously didnt understand the idea of the APIHandler.
    The APIHandler doesnt prevent you from using your own interfaces it only gives out standards.
    Its the same with HTML. Afterall its just an XML standard defined by the w3c. You could still write your own tags but only browsers that support your tag are able to resolve it. You can not say your Website is w3c compliant and make sure all browsers that support w3c standards can read your page, if you use custom tags.
    I am trying to create some kind of w3c for bukkit plugins here.

    It even throws a NoPermissionsPluginFound exception.
    It is the part of the Plugin developer, who makes use of the PermissionsAPI, to decide what to do in that case.
  12. Offline


    Sort of. The idea would be to allow some extension.

    Plugin authors could either use the standard API and get 100% compatibility, or use a non-standard one and have to say that they only support one or two of the currency systems.

    Also, the idea is that any non-standard methods would eventually be made part of the standard.

    The standard method could have required methods, recommended methods, allowed methods and then non-standard methods.

    As the backend methods get more developed more methods will be set as required.

    I guess I don't want to see a single "gate-keeper" for all the interfaces.
  13. Offline


    Ehm, you are simply checking every plugin, and if a plugin implements a given interface it will be registered. Also your plugin won't reset the registered plugins after disabling your command. For example I'm using often the “reload” command.

  14. Offline


    Oh, you are right, now the APIs reset when the APIHandler gets disabled.

    I hope you didnt get the feeling that i was gatekeeping the Interfaces.
    The developement of the interfaces as well as the development of the APIHandler itself is meant to be designed by the Community.
    So if you have a method that is not implemented, just implement it yourself.
    Its all hosted on the wiki.
    Everyone can edit that!
  15. Offline


    I am not really sure how that would work. There needs to be some way to define the "official" API.

    My suggestion for different levels is so that there is a way to organise things.

    Maybe it could be required - recommended - defined, so that methods can be added in a hassle free way.

    For example, anyone can submit a page that is marked as a "defined" method but there is something like a vote mechanism to move something to recommended/required.

    Votes could be given on the basis of what that person has authored (either backend/frontend) or something. However, nobody has the right to block a person adding a defined method.
    Alternatively, methods could be marked as supported with a percentage (maybe one for front and back-end), so this method is used by 50% of plugins and supported by 75% of backends.
    Btw, I am not suggesting that you would go power-mad :), but it is worth setting the foundations right.
  16. Offline


    Seriously Raphfrk you talk things into the ground before they even got realized and you already have solutions for problems that dont even exist (yet).
    Why dont you start using/coding the APIHandler for your plugins and then request what is needed instead of thinking what could be and what you think would be great?
  17. Offline


    I think Raphfrk don't want to bother you, but if you don't manage a usable standard interface it don't work. I mean if there are plugin supporting this, and then everything has to recoded the starting developers maybe feel ignored.

  18. Offline


    Is it correct that your pull request only includes a new file structure (everything inside the apis package) and you renamed the isEmpty method to isRegistered?
  19. Offline


    And unique/multiapis, because you had a todo how to manage this.

  20. Offline


    Hoooray, i managed to merge branches ....
  21. Offline


    Well, maybe I over-think things :), but just trying to ensure a solid foundation.

    I think the suggestion to "just do it" is a good one.

    What might be worth doing is to try to get a back-end plugin to actually use the API. Maybe you could talk to one of authors of the permissions plugins (either one of the Permission splinters or group manager) and see if they will support the methods.

    It is a bit of a chicken and an egg problem at the start.
  22. Offline


    I tried to use my in the Permissions plugin from TheYeti and it is pretty easy if you simply let implement PermissionWrapper your Permissions interface. You only have to rearrange one method, but the “permission” or “has” function only need the world and username of the player instance, so the three parameters are enough. I didn't look at GM yet.

  23. Offline


    One option would be a bridge plugin (or just implement it directly into this one) that does that automatically.
  24. Offline


    The only “problem” is, that the plugin has to support his functionality (as this implement this interface). With only two methods this could be okay, but for example there should be an advanced PermissionsInterface where the plugins could retrieve a value (e.g. an integer). There you have then 4 more methods.

    So the best would be, if a plugin simply could support a “interface retrieve”-Interface which returns the interface with the functionality (the Permissions plugin uses “getHandler()”).

    Okay I added a quick & dirty bridge for the Permissions plugin:

    I don't test if the selected plugin is ready to use, so I call this quick & dirty :p

  25. Offline


    Second that.
  26. Offline


    You and nijikokun have most obviously no clue what you are talking about.

    Anyway noone seems to want to work together. Rather go on and rule out other plugins so we all have to code 10 times more....
  27. Offline


    Second that. There is no usable system, so a wrapper/an adapter could replace another one. For example if I want to program a economy plugin. Either other plugin developers has to import my economy plugin or I write two plugins (like GM does) to simulate an other economy plugin. And there we have a problem that there is no “default” economy plugin. So some uses iConomy, other use Essentials (I think they support economy?). So either any plugin developer using an economy plugin has to support all of them, or all economy plugin has to define a plugin which any economy plugin should provide. But if you decide to do something like this, you simply could use APIHandler. Because this does the same.

    nijikokun you are right, that somebody could now make an APIAPIHandler, but at the moment there are only two developments (Isabaellchen's and mine). But these plugin is quite nice, and mine is not released and I only use it to get experience to improve APIHandler. Also have you a better solution for this problem? I think this is the second best (best would be a internal system like Raphfrk implemented).

  28. Offline


    Let <some-feature>-dependent plugin authors decide which <some-feature> system they want to use on their own, and let <some-feature>-providing plugin authors provide the full set of features they want without being constrained to some what some APIHandler deems acceptable. Dependency management might be useful (write a plugin that can download and load other plugins), but a bunch of glue trying to combine all plugin feature sets as interfaces into one plugin makes no sense.
    If there's just one "approved" interface, then any plugin that supports features outside of that "approved" interface needs its own wrappers anyway. On the opposite end of that is every plugin providing the same interface, in which case there's no point in having more than one plugin, which would completely remove any need for any kind of APIHandler.

    If what you're trying to achieve is entirely different than that, please elaborate, because that's all I'm seeing.
  29. Offline


    Okay, but why shouldn't developers support more features than the “approved” interface? If a plugin needs this special features it couldn't use the APIHandler, but in the most cases the plugins only need some basic methods. At the example permissions only “has(String, String, String)” and “getGroups(String, String, String)”. So if you then add a new feature, you simply could add the needed methods (as long as there are no naming conflicts). And if you want to support others APIs you already have to write an (quite bigger) adapter to simulate another plugin.

    And that it is easy you could see in my source code. I implemented for both major permissions plugins adapters (GroupManager, Permissions). But you have to note, that this is not the intended way to support the APIHandler and that these classes are quite bigger than the prefered way. There the plugin developers only implement the “PermissionsInterface” and simply have to forward two methods. If the APIHandler would allow to add these Interfaces not in the main plugin it the permissions plugin is quite easy to implement. The PermissionsHandler class simply implement this interface and you are quite done. One method is already implemented and the second you could only have to add a few lines.

  30. Offline


    For the ten F***in thousands time. IF there is a method that you want to have in the Interface go add it!!!

    This is whole thing is !not! made to make Restricitions!!!!
    What the hell is so hard to understand about that?

    Each argument against the APIHandler contains the idea that the APIHandler is making restrictions to coding plugins.......
    Which then leads to the assumption an extra interface is needed which makes need for an APIAPIHandler...... (Or a wrapper for a wrapper).
    Seriously if you cant think beyond this point, then it is not my or the APIHandlers fault.

    Its all in the wiki. Im offering to add people to modify the git repository.
    Still noone has applied or changed anything here (except xZise) but all complain about restrictions restrictions restrictions...

    Im sorry for raging here but im seriously fed up telling people how the wheel works and why building streets would actually make sense....
Thread Status:
Not open for further replies.

Share This Page