Services API: Economy

Discussion in 'Plugin Development' started by sk89q, Apr 12, 2011.

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


    I had a brainwave when I came across this and figured I would contribute my thoughts.

    Standards are always a good thing. No one forces anyone to use them, but it's good practice. Imagine what internet would be like if we didn't have standards (you won't have to think back too far). It was a mess of sloppy code and hacked-up design principles that only one specific browser supported. The Bukkit plugin situation is like this in that there's no standardized protocol for any of this plugin communication, so plugin makers have to resort to checking support for specific plugins and API's. This is messy, and like the old web, it needs to go.

    I'm just an amateur, and I haven't messed around with Bukkit itself much, but hypothetically this is how I would do it (there might be an easier way to do it that I'm not aware of, I know the ins and outs of Java, but not on a scale like this per-se). I would have an interface in Bukkit, call it say, "Service." The service interface would have a few key methods that register the service, provide service info to bukkit, etc. The Service plugins would implement the Service interface and register themselves under a generic name, for example, "Economy." Plugin makers would have to agree on a service name to use for certain aspects. Then have a Server.getService( String serviceName ) method that returns a handle to the plugin that is registered as the service

    However, now we have a problem. A "Service" interface isn't specific enough to provide anything meaningful to the plugin. My proposed solution to this problem is that each service plugin, or service host, provide another interface, for example "EconomyService" that details the specifics of a given service. These could be standardized interfaces provided on the Bukkit wiki and community driven. Any service host that wants to provide an economy could simply implement this interface and the "Service" general interface to provide interoperating plugins the ability to query the service using standards-based method calls.

    The TL;DR of this suggestion is this: Have a general Service interface supplemented by a SpecificService interface provided by the Service Host. The Service Client would then use standards-based calls to interface with the Service. Any plugin could be assured that if standards are followed that these methods would work for any plugin.

    Feel free to tell me that this is an awful idea, that it's a great idea, or that it just wouldn't work for X reason.

    Before I even hit post I've identified a few problems. I'm pretty much just laying out ideas to see if anything clicks.
  2. Offline


    Actually this thread is about this. It tries to determine which methods are essential enough so it should be in the API.

    Since days/weeks Bukkit as a service manager. Maybe this will do your job handling the services. I don't know how it works and if it does what you suggested.

  3. Offline


    I don't understand completely. You said that Bukkit has a service manager but a javadoc search shows nothing (is the javadoc current or is it the recommended build?)

    I agree, obviously you can't have every possible type of service with a built in interface in bukkit, so I suggest that there be an overarching service manager in Bukkit and then services themselves can define what type of service they are, and to define their own interface, but these definitions should conform to a sort of standard laid out by the community. In this way, anyone can define any sort of standard they want but it's much more efficient for programmers to conform to a widely accepted standard for interoperability, and when new mods are developed for new things, the developers will create their own standards which will be published and made available for use by plugin authors.

    It's merely an ease of use type issue where the onus is on the developers to try to sort out this mess of programming incompatibility that's been created because of the lack of any uniform standards.

    There could be EconomyService interfaces, WarpService interfaces, RoleplayService interfaces, any interface that anyone wants to publish, it could be made and then eventually standardized by the community.
  4. Offline


  5. Offline


    If I wanted to add a Service type, Should I add it to Bukkit itself and submit a pull request?
    If so, what namespace and other conventions should I use?
  6. Offline


    Depending on your service? By default it isn't necessary to create a pull request with a service, but this could allow other plugin developers to use the service without adding a third party plugin.

  7. Offline


    I want to add a chat meta data service to PlayerChatEvents. Several users have asked for IChat support from my irc plugin. I figured that adding a service where IChat can query for extra information would be a reasonable approach, and would allow me to support any chat message modification plugin without needing explicitly acknowledge it's existence.
  8. Offline


    Hmmm actually this thread is about a economy API and not about (chat) services in general. And I don't know what do you want to fix. That your IRC plugin don't get the iChat formated messages?

  9. Offline


    Fair enough:

    Actually, its the other way around, I want IChat to get extra data from my irc messages.
  10. Offline


    Wouldn't the best option be to format/color the messages yourself - you probably need a slightly different output anyway, so ppl can recognize it's a irc user and not ingame.
  11. Offline


    Color isn't the problem. You want to have metadata about the message. There may be some plugin that acts on chat messages, and you might not want it to do anything for messages that didn't originate from an in-game player.
  12. Offline


    But won't you always have plugins that just write out whatever they want without adding metadata?
  13. Offline


    No real API is needed, i guess a bunch of simple standard interfaces on common plugins such economy, region safety etc would help every aspect of the bukkit plugins development. The developers would just need to agree to use it.
    GatsbyTheGreat likes this.
  14. Offline


    Ehr on one hand you said no API is needed, an on the other hand you saying:
    Where is the difference between an API and a standard interface? And if a economy developer didn't agree to use it: Wayne! Either (s)he is so popular, that everybody is using a own detection implementation, or nobody is using it.

    It is like in Bukkit: You could make your own CraftBukkit implementation and as long as you implement Bukkit's interfaces, the plugins should work.

  15. Offline


    Why are a lot of you guys making a big deal over this? It's going to be working in the background, letting you use all economy systems, without you even noticing! Less code too. It's not like you're the guys that are going to be implementing this anyway. <--- This comment is directed to the people who reject this.

    I support this, and I think a stable API should be released with just basic functions at first, before expanding on it.

    EDIT: Just noticed the date.. I hope it's going along well though...
  16. Offline


    Hopefully, but the main problem is, that I see no intervention from the economy plugin developers. I mean, for the popular (especially iConomy) this here would cause that not every server have to use iConomy.

    And I already noticed, that Register as a non lib isn't very handy and cause errors, if the plugin authors don't use the same version. Also Register does enable plugins on its own. So if you disabled a plugin, Register ignores this, and will enable the plugin, if somebody want to uses this.

  17. Offline


    I know that bukkit's team like doing things by themselves, but is this case I really, really thing that they should make iconomy the official bukkits API, I bet that Nijikokun wouldn't mind and damn, iconomy is already the most used plugin on minecraft isn't it ?
  18. Offline


    No, some other plugin like CB, WG or WE is the most used probably... And why should they use iConomy? What about all other devs that worked on their economy plugins? We should just have an API for this so anyone can use whatever economy they want, and devs don't have to support them all.
  19. Offline


    But it is completely overloaded. Actually I use only some methods (3 afaik) and every plugin developer has then support all what iConomy support. But I guess, that in the most cases only basic methods (those are listed here) are relevant. I mean you could add comfort methods (e.g. transfer or add) which are simply sequences of the basic methods (set and get for example). My suggestion:

    public interface EconomyService extends Service {
        double getBalance(String name);
        void setBalance(String name, double balance);
       /* Comfort methods */
       boolean hasEnough(String name, double value);
        void transfer(String from, String to, double value);
        double add(String name, double value);
        // Some other comfort methods?
    public abstract class AbstractEconomyService extends EconomyService {
        public double transfer(String from, String to, double value) {
            this.setBalance(from, this.getBalance(from) - value);
            this.setBalance(to, this.getBalance(to) + value);
        public boolean hasEnough(String name, double value) {
            return this.getBalance(name) >= value;
    Maybe some format method could be also added. And for example if other plugins allow loans, they could override the hasEnough method or don't even extend the AbstractEconomyService.

    The plugin developer itself shouldn't use the class, but “lazy” economy developers could use the class.


    PS: Don't take the “lazy” personal. It has a reason why it is in quotes.
  20. Offline


    To be honest we shouldn't really care if we hurt any feelings here... we all know that iconomy is the best one, and the most used one too.
    So make iconomy the official one, and if you don't want to use it just disable it, the other developers can cry me a river ! I'm sorry but having to deal with multi-economy plugins its just frustrating !

    And they all tend to change to much from build to build, breaking all my plugins :mad:
  21. Offline


    It's not about feelings, it's about work. I wouldn't want all that work gone down the drain. Also, the point of this proposed API is to let devs only have to deal with this API, and let all econs interface with it, which means no, you won't have to support multiple plugins.

    Also, @xZise is right, the basic ones are all what we need, as devs rarely use the other features of the econ plugins.
  22. Offline


    Well maybe you're right, the only thing I really want is consistency, I don't want a group of developers crying they want the official API to be changed every other week, breaking all other peoples plugins... I see this happening all the time in other API's (not official ones).
  23. Offline


    To prevent that the API has to change often, the purpose of this thread here is to determine those. I mean, we could define a huge service, but every plugin has to support this. And I don't know how this is with other plugins, but either xWarp or Qukkiz only needs the two (get and set). The hasEnough() might be helpful and could get a default implementation (like I coded before).

    And maybe a String format(double) could be added, but then I don't know which methods are missing then. It seems that your plugin(s?) also use(s) iConomy. Now tell me, what your plugin needs? Maybe my ones are so spartan and the most of the rest needs the special stuff.

  24. Offline


    To tell you the truth, all we need is a few basic things like getBalance(), .add(), .remove(), and hasEnough(). Really, the only things we definitely need are getBalance, as the above can br simulated with one operation or if statement.
  25. Offline


    For things like economies, where more than one can exist at a time, using this method of allowing plugins to define how things are handled is great. However, with things like permissions and area protection, it doesn't make sense to have multiple instances of the service. For area protection, I suggest something similar to how permissions are being implemented, but with Location objects in addition to the normal parameters in the Permissable interface.

    Maybe it would be even better to add another layer of abstraction and let permissions be defined with arguments as events, so a permission could be defined as "let player X do action Y, but only if they are wearing item Z on their head".
  26. Offline


    Already done:
  27. Offline


    Regions API is needed as well
  28. Offline


    For now, could someone just pull the essentials of Register into bukkit? That would be awesome. =)

    FTW temp fix!

    For the services API, maybe it would be best to have each service only have a VERY small set of methods, (Ones that would either all be implemented or not at all) perhaps even just one, and then have each plugin register many services. That way, a plugin could check that just the services it needs are implemented, and then only use those.
  29. Offline


    I like the reusability of this method but it should be a little safer in case a player name equals a faction name or something.

    It would make sense to accept an "Entity" or some sort of super-class/interface to Player, then other plugins could create other entities as long is they implement the parent (i.e., a plugin to add factions with a shared "faction" wallet/bank would call the method using Faction which implements Entity
  30. Offline


    Take Register's Method interface.

    Make each economy plugin implement the Method interface themselves.

    Then get them to add themselves to Bukkit's ServicesManager.

    Rather than making Register responsible for supplying the implementation, we make the economy plugin authors do it. Once that happens, we can pare down Register until we're down to that single interface.

    For example, iConomy could do this:

    public class iConomy6Method implements Method {
        // Insert code from Register
    // In onEnable
        Method myMethod = new iConomy6Method(this);
        getServer().getServicesManager().register(Method.class, myMethod, this, ServicePriority.Normal);
    On another note, have you read the WorldEdit source code? Best use of annotations I've ever seen.
    GatsbyTheGreat likes this.
Thread Status:
Not open for further replies.

Share This Page