New way to handle plugindata

Discussion in 'Bukkit Help' started by Sky.NET, Jan 6, 2011.

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


    In the 'Flatfile' thread it went to offtopic discussing wheter flatfile is okay or not.
    In my case flatfile is not okay.
    But am not god, and my opinion isnt law.

    So i did a short brainstorming about this issue.
    Fact is: Many people were using flatfile.
    Fact is: Many people prefer flatfile instead of MySQL or anything else.
    Fact is: They want to have it back in bukkit.

    After a very intense discussion about flatfile and MySQL/other db systems i came to a point to say:
    Bukkit should leave the decision by the ones who are mostly affected from it, the users who run a minecraft server.

    I recently posted a picture of how bukkit 'could' handle all data given from and requested from plugins without killing performance or causing extrem console/log spamming with java exceptions relating to plugindata itself.

    Now i decided to show it in a more professional way (i am using 'XMind' to generate this kind of brainstorming sheets)

    EDIT: the only exception here is, if data is used frequently, is MUST be stored into a fast db-system, not flatfile. In that fact, bukkit must implement a way to show that data in plain-text form (e.g. write it down to a simple text-file) but that shoulnd be a problem.

  2. Offline


    I just created an account to make the same suggestion. It makes much more sense to have Bukkit handle the data rather than each of the plugin authors handling it independently. Plus, it cuts down on individual plugin setup for the admin hosting the server.

    As it is now, admins have to create different DB's/Tables for every mod that uses data. In some cases, we don't get a choice in how the plugin accesses data. Some plugins even install their own DB software. Obviously, this is not the best solution.

    If bukkit were to centralize DB access and give Admins the choice in which DB to use, (Flatfile, SQL, MySQL, SQLLite) that would be awesome.

    You could also take the opportunity to create a uniform way for dealing with plugin settings, saving them via a centralized system, and having all settings able to be modified and reloaded in-game. Hopefully at some point in the future, Notch will add some UI classes so that such settings could be easily manipulated. But in the short term, text commands would suffice.
  3. Offline


    Would you be intending that the plugin uses the system every time the parameter is accessed?

    I wrote a similar suggestion in the suggestion tracker.

    The idea was that if an object implemented a .toString() and a (String) constructor, then any object could be stored in the database.

    This actually seems to be what the standard java Serializable API does, so it might be better to implement it that way.

    However, storing data as strings would allow it to be hand edited in SQL.
  4. Offline


    Nononono xD that would decrease performance, everything just has to be accessed through bukkit if it were changed or rerequestet from events (e.g. using ingame command /reloadconfig).
    In case of config: At starting the plugin, it requests its config from bukkit and store it in its local variables.
    In case of changing the config: the whole config (i.e. a hashtable) or just the parameter changed (better performance) would be send to bukkit to store it.
    In case of reloading saved config: It requests its data from bukkit.

    In case of Logs and very frequently accessed data: the log-line logged would be send to bukkit, and then deleted from the memory of the plugin. Same with fast accessed data, it should be deleted from the pluginmemory when its not used anymore.

    I posted my own ticket including the picture above =D thanks for the link Raph.

    That could be one possible option in whitch objecttype data is handled.
    (IMHO you could change integers simply by hand too if stored in mysql 0o)
  5. Offline


    Bah your suggestion got an "assigned to" tag :).

    However, it is good that this is being worked on.

    I think something similar for help files would be great too.

    They are the kind of annoying thing that everyone needs, and there is no point in everyone coding their own.
  6. Offline


    Is that bad or good? I was thinking that it would be okay if there is one person directly related to my issue.

    I will do another brainstorming tonight and post it in a new thread related to how to handle every text in plugins and keep the possibility to handle the whole thing dynamically due to multilaguage (i am familiar with vbulletin that has a very nice phrase-based text system, that allows you to change everything with just a few clicks)
  7. Offline


    It's good, it means that they have someone looking into it.

    The bah (and :) ) was just saying that they picked your suggestion rather than the ticket I submitted.
  8. Offline


    lol, they dont think its possible now...
    IMHO it IS possible, now or later...
    Maybe i will write a complete sample and give the source to bukkit team, dont know why it shouldnt be possible, maybe there is not enough manpower?
  9. Offline


    Actually, I think he was referring to your request to change the original post to be from you (instead of anonymous). Their software doesn't let them change that (yet).

    Also, you must have set Dinnerbone as the person it was assigned to? He was just saying that assigning tasks is the responsibility of the team not of people who submit issues.

    In fact, that was what prompted my original response, I thought that they had accepted the task and given it to Dinnerbone.

    It is possible to submit code to the project via a github pull request to their source site However, if they plan to implement it anyway, then you could be wasting your time.

    You would need 2 things

    - a bukkit request for the API update
    - a plugin that implements the API for (say) SQL

    Also, they are probably not accepting anonymous pull requests until things have settled down.
  10. Offline


    The way that I imagine this would work is that when a plugin is started, it requests table data from Bukkit. If there is no data table for the plugin, then the plugin tells Bukkit what tables and fields need to be created for the plugin, and tells Bukkit what field (if any) to use as the index for each table.

    If the data does exist, then the Plugin can request data from Bukkit by initiating a DB query to Bukkit and can write/update by performing an insert/update.

    Essentially, Bukkit becomes a DB API or Wrapper. Bukkit deals with what type of database it is, logging into the DB, Creating the tables, and handles the actual DB Queries, Inserts, and Updates. This makes it easier for the plugin authors to load/save data, and makes setting up and maintaining a server much easier for admins. Overall, this is a win/win for everyone but the Bukkit team, who has to write the code. ;)

    Some Examples from a plugin author perspective:
    In the case of a chest protection plugin, if the plugin hasn't run before, it tells bukkit to create a data table for the plugin. The table would include the coordinates and permissions for the chest.

    When a chest is created and protected, the plugin sends a DB insert request to Bukkit with the info on the chest. Unless the chest is destroyed or the permissions are changed, there's never another DB write for the chest.

    When bukkit loads, the plugin requests all of the chest info and holds it in memory. It does not make any further read requests from Bukkit.

    Ideally, for optimal memory usage and DB performance, you'd load the chest info into memory when a player was within a certain distance of a chest. You don't want to load the data when the chest is accessed because that would be a lot of unnecessary loading and unloading. However, I don't know how object management is handled on the Minecraft server, so this is best left to folks who are actually doing the coding.

    Another example would be a plugin like Adventurer which has variables that stick with a specific player. In this case, the tables are set up the same way when the server is created.

    However, when a player connects, the plugin requests that player's info from the DB. When the player does something that changes the variables stored in the DB, the changes are updated in memory. In this case, you shouldn't be calling a DB write for every change to the character. Instead, the plugin checks the in-memory data for updates at a regular interval, and at that point calls for Bukkit to update the DB.

    When a player disconnects, you flag the player as disconnected, and at the next DB update interval, the plugin sends the player's info to the DB, and the player info is unloaded from memory.

    From an admin perspective, all you would have to do to install a plugin would be to put the plugin dll (or jar, or whatnot) in the plugin directory, update your (or whatever Bukkit uses) adding the plugin to the plugins list, and then edit the plugin settings file to suit your needs. (or better yet, change your settings from within the game.) You wouldn't have to set up any database info... You wouldn't have 50 flatfiles in your root directory.
    Sky.NET likes this.
  11. Offline


    Any other thoughts on this concept? Perhaps if it's not included directly in Bukkit, it could be a plugin since plugins are going to be able to talk to each other?
  12. Offline


    They are apparently going to implement inter-plugin communications.

    This would mean that a plugin author could define the API.

    On my opinion, properties/data management is something every plugin needs, so it seems like a reasonable thing to include in the API.
  13. Offline


    Any news on that?
Thread Status:
Not open for further replies.

Share This Page