[Discussion] What Configuration type do you use for your plugins?

Discussion in 'Spigot Plugin Development' started by John_Willikers, Jun 5, 2018.

  1. Hello! I notice a Majority of people use YAML for their plugin configurations. I have always used JSON. I was wondering if there were other methods people use for storing configurations.

    Also tell me why you use YAML, JSON, etc. The reason I use JSON is because I love this library and http://www.json.org has a very easy and intuitive way to see how JSON objects are built. Its also really nice not only for storing configurations, but I have used it to Store block locations in JSONArrays.

    I can't wait to see what people reply with :)
  2. ScarabCoder

    ScarabCoder Retired Resource Staff

    I use YAML because it's what comes with Spigot (though GSON is shaded into Spigot as well) but mainly because it's what all server administrators are used to. The few times I've used JSON, I've had to teach nearly everyone who used it what the correct syntax was for JSON. Absolutely no reason not to use JSON, not to mention getting object serialization from YAML.

    If you're talking about data storage, you could use JSON, though I've found flat-file (in that way) isn't always ideal and like to stick to SQLite (still flatfile, I know) or MySQL if it involves working over a network.
    • Agree Agree x 3
  3. usually on any of my plugins where I'm storing data I use MySql(No reason not to since it's not hard to store on the localhost, and MySql Servers dont cost a fortune. My McHost gave me mine for free.). I have a system in my Rp_MMO plugin where it takes the players MMO data and copies it to a JSON file so I can read and update Stat values and such. I might go back and Actually make a Custom Class and store it there. But thats for another day.

    Also I'm curious why isn't flat-file isn't always Ideal. If you could name some scenarios that would be nice so in the future I wont waste my time on it.
  4. I use yaml for everything bukkit related. Why? Because it's provided by the API and isn't total shit. It also helps that it's been established and everyone k ows how to edit them by hand. Even data storage, there's always a scenario where a server owner would like to easily go in and change something for whatever reason, and yaml is what they're used to seeing. The only downside is making a single file too big (see world guard region file) which slows reads/saves a _lot_. Best is to separate things into their own files (see essentials player files). But then you get that one person that bitches about ftp transfers taking forever cause tens of thousands of files..

    SQL is usually overkill 99% of the time (and 99% of devs think they are that 1% exception). It's comparable to people wrapping things in async tasks for "speed." If you have to question it, this isn't your option.

    Json is ok, I guess. But that involves shading your own library or hooking into nbt. It's just as fast/slow as yaml and just makes it harder for you as a dev (unless you're a fanboi thats been using it for years already and know your way around), and the server admin editing files (yet another syntax for 12 y/o's to learn and get wrong). Fun fact: The json library that ships with Java sdk is actually pretty simple to use, yet so many people want to include some other weird library).

    In conclusion. Use whatever you are comfortable with and you think the end user (server admins) will be comfortable with, too. What anyone else says is irrelevant (including me).
    #4 BillyGalbreath, Jun 5, 2018
    Last edited: Jun 5, 2018
    • Agree Agree x 2
  5. DavidDevelops


    I just wanna point out, Ii agree with you mostly but... "What anyone else says is irrelevant." So its irrelevant if they dont agree with you? Lol, OP asked for THIER opinion and they can give it and its still relevant
    But for the real post i agree
  6. Optic_Fusion1

    Resource Staff

    Just like @ScarabCoder and @BillyGalbreath i personally use yaml and for pretty much the exact same reasons they do, it's already added to the source it's easy to use and edit
  7. Sorry, that's worded in a weird way. Meant that my own opinion is irrelevant as well. Edited for clarity ;)
  8. Strahan


    For me, using SQL isn't just about performance it's about preferring the use of the SQL syntax for data retrieval over the YAML file options.
  9. I prefer a Lambo over a Kia. Doesn't mean it's not overkill ;)
  10. Strahan


    I'm confused as to why you took my post to be arguing that SQL isn't overkill.... just pointing out there are reasons other than said overkill performance that may drive devs to use it.
  11. Because you quoted me saying it was overkill
  12. Strahan


    I guess you aren't the only one wording things weird, heh. I was trying to get at the fact that it being overkill is not always relevant, as there are other reasons for using it. Just didn't put it well I guess.
    • Friendly Friendly x 2
  13. MiniDigger


    I personally use json as the tooling around it is way better. I can just shove my DTOs into gson and write it to a file in one line.

    About databases: most of my projects use hibernate to interact with a database. I use the DB for long term storage and for data that needs to be shared across all servers for accessible to the web (for a website or smth like that). When you store playerdata it just becomes unmanageable to use files. Imagine I want to store 20 attributes for each player. Let's also imagine that after a week my server had 1k unique players. That now either 1k files with 20 lines or 1 giant 20k lines file. Both not really nice in terms of lookup performance and memory usage. A database allows me to easily structure and fetch the data. As the database is deployed locally (and replicated over hosts), the initial (async) data load on join and the async saves are not demanding at all.
    • Agree Agree x 1
  14. I would say unless the data you are storing is in the thousands, then using SQL isn't going to make a difference. SQL is for really large databases. But then again, it can be really useful so it depends on the project.
  15. I wish Bukkit would allow us to store data to the player nbt file (Forge allows it and it's a godsend) for things like that.
    • Agree Agree x 1
  16. For me, YAML for configs, JSON for flatfile storage, SQL if it's related to player data at all
    • Agree Agree x 1
  17. Optic_Fusion1

    Resource Staff

    I mean, couldn't you rip out the code from NMS and the client and do your own thing?
  18. I know what you mean. I actually prefer SQL over JSON/YML just because the simplicity of linking data. I remember I used to use a masterfile in JSON that would store a players IG rp name and spit back a uuid so I could find their playerdata that was uuid.json. in MySQL you just use foreign key injection and search for that key. It's lovely
  19. Yeah but then when the next NMS version comes out you have to pray they didn't mess with what your tapping into or they could just reobfuscate it all.
  20. Optic_Fusion1

    Resource Staff

    Re-read what i said, you don't need to worry about the obfuscation as much as you think, you'd mostly have to worry about them messing with the NBT system its self