Centralized storage api for bukkit plugins

Discussion in 'Bukkit Discussion' started by werfu, Aug 9, 2011.

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

    werfu

    I've been using Bukkit for a while, and haven't done any plugins myself, but I've kind of became annoyed from the lack of uniform, standardized storage between plugins. Some plugins wants yml files, other xml, or some propose database backends, and all of each of these solution are tailored to the plugin's author wishes. Being both a programmer and a server admin, I don't quite understand why there's no centralized/standardized API within Bukkit itself to abstract the storage from the plugin perspective and that would provide a unique configuration hassle for the server admin. Now that the permissions are being pulled into Bukkit, I think storage could be a good proponent to be next.

    I'm not a pro Java developper (I mostly do PHP and .Net), but I've used a few time Hibernate. I'm not quite sure its the way I'd like Bukkit to take, as the configuration file is a PITA, but I think other JPA solution could be explored. Annotations would be pretty easy to include for plugins developers. And as a huge advantage, is that a centralized framework could be easily expended to support every database needed (Bukkit on MSSQL, why not?). It could also be possible to edit the config by loading directly the beans from the database and browsing/editing the objects.

    So, how does it sound, am I too idealistic or does it bring inspiration out of peoples mind?
     
  2. Offline

    Drakia

    There is already persistence built into Bukkit, it sucks so nobody uses it.
     
  3. Offline

    werfu

    I knew that the answer couldn't be because nobody though about it. I guest that if you want something done you gotta do it yourself. I'll have a look at the persistence API and see how I can submit patches for modules I use.
    Thanks :)
     
  4. Offline

    Sleaker

    @werfu - Bukkit has it's own yml Configuration class - it's the standard that most plugins use for their configurations, some just decide to use json, xml, or properties (javas builtin) -

    Also I don't think the persistence API is able to be changed - it's netbeans - so not too much to go changing there.
     
  5. Offline

    Drakia

    Yeah, plugins should use the built in yml based config class, but some devs find yml too difficult for end-users to comprehend.
     
  6. Offline

    werfu

    I don't quite understand what you wrote. Bukkit persistence API is based on Java beans and can only use YML? Why couldn't it have a mysql or sqlite backend?
     
  7. Offline

    IcySeal

    The reason it is tailored by the author, to my understanding is that differing problems are resolved with differing solutions. Basic plugin settings would be most easily accomplished with a yml, while storing mass amounts of data, such as block data per chunk would best be dealt with by databases.
     
  8. Offline

    Sleaker

    no.. the BukkitPersistence uses netbeans meaning whatever you configure the storage as in the bukkit.yml is what it uses for persistence.. It already supports mysql - people just don't use netbeans because it's not exactly efficient from what I understand. THe whole reason why bukkit added built-in persistence via netbeans was so server admins could choose how to persist their data via plugins that hooked it, instead of the plugin choosing how to store it.

    @IcySeal - there's a diff between bukkits Configuration class and it's persistence methods though.
     
  9. Offline

    IcySeal

    @Sleaker - Yea, I know that. I just remember a post by one dev about responsibly choosing your storage method. And I know there are differences, as I have used both for storage before. Personally I much prefer the Configuration class to writing my own flat file formatting classes.
     
  10. Offline

    werfu

    If the storage mean is abstracted to the developer and class can be loaded transparently, like collections being persisted, why would developers use their own solution? I do quite understand that configuration stored in database is a lot more difficult to edit from a user point of view, but if a special utility was provided to do so, I don't quite see why it couldn't be more widely adopted.
     
  11. Offline

    Sleaker

    @werfu - the general rule of any plugin configuration file - Never store it in a db - Why? because you have to have the configuration to even setup the database connection...
    It's not a matter of it being 'difficult' it's a matter of the logistics of the matter just plain not working.
    Even with a utility it's still not possible. And on that thought, why would you provide another extra utility to do configurations? Is that utility also going to need a configuration file/db for itself?
     
Thread Status:
Not open for further replies.

Share This Page