Thread: We need an API

Page 8 of 17 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 164
  1. #71  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,606
    Thanks given
    242
    Thanks received
    979
    Discord
    View profile
    Rep Power
    1281
    Quote Originally Posted by Ignatius Baccus View Post
    I already made a "plugin" system for my RSPS that is very similar to Bukkit.
    care to expand?
    .
    Reply With Quote  
     

  2. #72  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by Supah Fly View Post
    care to expand?
    Well what I'm doing is per-server event manager. Each event manager holds just a list of listeners, can be used to dispatch events and register more listeners.

    About Listeners
    To make a class a listener you must implement EventListener.
    Code:
    public class Example implements EventListener {
    }
    To listen for any event you need to specify a method with a single argument, being the event you are listening for, as well as annotating the method with @HandlesEvent
    Code:
    public class Example implements EventListener {
    
        @HandlesEvent
        public void onExampleEvent(ExampleEvent event) {
            // do stuff
        }
    
    }
    You need to register the listener to an event manager also.
    Code:
    getServer().getEventManager().registerListener(listener);
    Events
    To make an event all you need to do is extend Event.
    Code:
    public class ExampleEvent extends Event {
    }
    To dispatch the event just use
    Code:
    getServer().getEventManager().dispatchEvent(new ExampleEvent());
    There is no need to register events. All listeners of the event manager will handle the event.

    Plugins
    Basically top-level implementation of a listener. Plugins are simpler with my system than in Bukkit.

    To make a plugin all you need to do is implement Plugin.
    Code:
    public class ExamplePlugin implements Plugin {
    }
    If you want to do something when the plugin is enabled, there is an event for that. Just handle PluginRegisterEvent.

    Code:
    public class ExamplePlugin implements Plugin {
    
        @HandlesEvent
        public void onRegister(PluginRegisterEvent event) {
            // do stuff
        }
    
    }
    Now you might be wondering how the API knows what class to use as the Plugin implementation. This is done in the meta information inside a file called plugin.ini.

    Code:
    name: ExamplePlugin
    description: This is just an example plugin...
    version: 1.0
    main: exampleplugin.ExamplePlugin
    Performance Issue?
    There is extremely low performance impact due to the way I'm caching listener events. Instead of having to use heavy reflection iteration each time an event is dispatched, upon listener loading it performs these iterations and maps them in a registry to the listener.
    Reply With Quote  
     

  3. #73  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,606
    Thanks given
    242
    Thanks received
    979
    Discord
    View profile
    Rep Power
    1281
    Quote Originally Posted by Ignatius Baccus View Post
    Now you might be wondering how the API knows what class to use as the Plugin implementation. This is done in the meta information inside a file called plugin.ini.
    don't you think it would be smarter just to have the plugin be a jar in a certain directory then use reflection at runtime to go through the directory? you already do essentially the same exact thing as bukkit, why not take a lesson from the way they load plugins too? reduce the redundancy.

    Performance Issue?
    There is extremely low performance impact due to the way I'm caching listener events. Instead of having to use heavy reflection iteration each time an event is dispatched, upon listener loading it performs these iterations and maps them in a registry to the listener.
    well you'd kind of have to. it doesn't make sense for it to go through and do a ton of reflection each time you wanted to raise an event lol.
    .
    Reply With Quote  
     

  4. #74  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by Supah Fly View Post
    don't you think it would be smarter just to have the plugin be a jar in a certain directory then use reflection at runtime to go through the directory? you already do essentially the same exact thing as bukkit, why not take a lesson from the way they load plugins too? reduce the redundancy.



    well you'd kind of have to. it doesn't make sense for it to go through and do a ton of reflection each time you wanted to raise an event lol.
    The plugins are in a JAR in the plugins directory... Also, looping through all classes and checking if they implement Plugin is a SUPER BAD idea. What if multiple classes implement Plugin? They will too. Some people have old versions and variations, as well as library extensions that are resources of other plugins.

    As for "have to" that's not that case at all. Bukkit doesn't do it my way either.
    Reply With Quote  
     

  5. #75  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,606
    Thanks given
    242
    Thanks received
    979
    Discord
    View profile
    Rep Power
    1281
    Quote Originally Posted by Ignatius Baccus View Post
    The plugins are in a JAR in the plugins directory... Also, looping through all classes and checking if they implement Plugin is a SUPER BAD idea. What if multiple classes implement Plugin? They will too. Some people have old versions and variations, as well as library extensions that are resources of other plugins.
    it's not a bad idea at all... it accomplishes the exact same goal without redundancy of declaring something twice for no reason. if multiple classes implement a plugin then it's safe to assume that they're plugins? i don't understand the question. you only do it once on start or whenever you want to "rebuild" the plugins. so i don't really get where you're getting the "it's a super bad idea" vibe from.

    "they will too" what? also the thing that will kill an api is inability to innovate or change. plugins are implementing the api, not the other way around. you shouldn't worry about plugins not being compatible.

    As for "have to" that's not that case at all. Bukkit doesn't do it my way either.
    It does in a majority of ways.
    .
    Reply With Quote  
     

  6. #76  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by Supah Fly View Post
    it's not a bad idea at all... it accomplishes the exact same goal without redundancy of declaring something twice for no reason. if multiple classes implement a plugin then it's safe to assume that they're plugins? i don't understand the question. you only do it once on start or whenever you want to "rebuild" the plugins. so i don't really get where you're getting the "it's a super bad idea" vibe from.

    "they will too" what? also the thing that will kill an api is inability to innovate or change. plugins are implementing the api, not the other way around. you shouldn't worry about plugins not being compatible.



    It does in a majority of ways.
    No it doesn't. It's not safe to assume that the author intended to launch that plugin... Also I don't think you understand what I was explaining because you said something completely irrelevant to my reasoning provided in the former.

    Loading all implementations of Plugin in a archive instantly kills innovation. People can no longer have dummy implementations for quick and easy plugin modifications. I never said plugins wouldn't be compatible, so I don't understand where you're getting that from either.

    And it's obviously not required. There is likely a better way to load listeners. Your persistence again only leads me to believe that you didn't understand what I explained... Please reread the last post, and reread this post... to make sure you understand everything.
    Reply With Quote  
     

  7. Thankful user:


  8. #77  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,606
    Thanks given
    242
    Thanks received
    979
    Discord
    View profile
    Rep Power
    1281
    Quote Originally Posted by Ignatius Baccus View Post
    No it doesn't. It's not safe to assume that the author intended to launch that plugin... Also I don't think you understand what I was explaining because you said something completely irrelevant to my reasoning provided in the former.
    yeah it is you already explicitly mark methods that handle events with annotations. why not do the same thing to plugins that should/shouldn't run? depending on how you want to implement it. it doesn't make sense for you to have to explicitly state "oh you don't know about this class but this is a plugin, run it, i promise it implements plugin" where you could just roll through the jar files and find classes that match that specific criteria.

    @Plugin(name = "Some Plugin", version = 1.0) is a better solution tbqh.

    Loading all implementations of Plugin in a archive instantly kills innovation. People can no longer have dummy implementations for quick and easy plugin modifications. I never said plugins wouldn't be compatible, so I don't understand where you're getting that from either.
    No it doesn't. Yes they can, even though I have no idea why they'd want to do that.

    "Some people have old versions" you even bringing up anything relating to "old versions" implies that there's going to/might be changes that makes "old versions" (of something) even relevant to bring up in this discussion.

    And it's obviously not required. There is likely a better way to load listeners. Your persistence again only leads me to believe that you didn't understand what I explained... Please reread the last post, and reread this post... to make sure you understand everything.
    well it's kind of hard for you to tell me that i should understand everything you said previously when you left a fragment of a sentence in there, "They will too." they will too what? so no i don't understand everything you said. i get your point but you're not being very open to the idea that there's still better ways you could do some things and i'm just suggesting some and helping you work out the problems with those suggested implementations. you don't have to treat me like i'm retarded and don't understand what's going on, because i do.
    .
    Reply With Quote  
     

  9. #78  
    Renown Programmer
    veer's Avatar
    Join Date
    Nov 2007
    Posts
    3,747
    Thanks given
    354
    Thanks received
    1,369
    Rep Power
    3032
    Quote Originally Posted by Ignatius Baccus View Post
    Well what I'm doing is per-server event manager. Each event manager holds just a list of listeners, can be used to dispatch events and register more listeners.

    About Listeners
    To make a class a listener you must implement EventListener.
    Code:
    public class Example implements EventListener {
    }
    To listen for any event you need to specify a method with a single argument, being the event you are listening for, as well as annotating the method with @HandlesEvent
    Code:
    public class Example implements EventListener {
    
        @HandlesEvent
        public void onExampleEvent(ExampleEvent event) {
            // do stuff
        }
    
    }
    You need to register the listener to an event manager also.
    Code:
    getServer().getEventManager().registerListener(listener);
    Events
    To make an event all you need to do is extend Event.
    Code:
    public class ExampleEvent extends Event {
    }
    To dispatch the event just use
    Code:
    getServer().getEventManager().dispatchEvent(new ExampleEvent());
    There is no need to register events. All listeners of the event manager will handle the event.

    Plugins
    Basically top-level implementation of a listener. Plugins are simpler with my system than in Bukkit.

    To make a plugin all you need to do is implement Plugin.
    Code:
    public class ExamplePlugin implements Plugin {
    }
    If you want to do something when the plugin is enabled, there is an event for that. Just handle PluginRegisterEvent.

    Code:
    public class ExamplePlugin implements Plugin {
    
        @HandlesEvent
        public void onRegister(PluginRegisterEvent event) {
            // do stuff
        }
    
    }
    Now you might be wondering how the API knows what class to use as the Plugin implementation. This is done in the meta information inside a file called plugin.ini.

    Code:
    name: ExamplePlugin
    description: This is just an example plugin...
    version: 1.0
    main: exampleplugin.ExamplePlugin
    Performance Issue?
    There is extremely low performance impact due to the way I'm caching listener events. Instead of having to use heavy reflection iteration each time an event is dispatched, upon listener loading it performs these iterations and maps them in a registry to the listener.
    stop abusing accessor methods and learn what an INI file is, because that looks more like yaml
    Reply With Quote  
     

  10. Thankful user:


  11. #79  
    Banned
    Join Date
    Mar 2012
    Age
    41
    Posts
    5
    Thanks given
    0
    Thanks received
    0
    Rep Power
    0
    I think that including performance beyond the primary of going for walks, discussing, products, things, battle fundamentals, multi-player, NPCs, outfitting, etc. right into a hosting server is ridiculous. Any content beyond primary performance should be through an API that way you aren't stomach ache the hosting server.
    Reply With Quote  
     

  12. #80  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,606
    Thanks given
    242
    Thanks received
    979
    Discord
    View profile
    Rep Power
    1281
    Quote Originally Posted by fabiogolf2 View Post
    I think that including performance beyond the primary of going for walks, discussing, products, things, battle fundamentals, multi-player, NPCs, outfitting, etc. right into a hosting server is ridiculous. Any content beyond primary performance should be through an API that way you aren't stomach ache the hosting server.
    fundamentals are pretty much what i posted in the original post. what do you think shouldn't be there?
    .
    Reply With Quote  
     

Page 8 of 17 FirstFirst ... 678910 ... LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Skills API?
    By Mister Maggot in forum RS2 Server
    Replies: 12
    Last Post: 08-24-2010, 01:17 AM
  2. What's the best API?
    By TriConnectivity™ in forum Help
    Replies: 12
    Last Post: 06-15-2010, 11:52 PM
  3. what API does RID use?
    By sylas in forum Application Development
    Replies: 17
    Last Post: 05-16-2010, 11:22 PM
  4. Networking Api
    By Karilz in forum Voting
    Replies: 6
    Last Post: 05-04-2010, 05:55 AM
  5. Which API?
    By Discardedx2 in forum RS 503+ Client & Server
    Replies: 35
    Last Post: 04-09-2010, 01:07 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •