New file formats in 1.3

banned-ips.txt

#Address, Date/Time, Banned By, Until, For

#Exactly the same as banned-players, but with IP addresses.

banned-players.txt

#Name, Date/Time, Banned By, Until, For

#All values are trimmed
#<-- these are comments and will be ignored by the parser
#The reason field may contain unescaped commas (, <--). It will be loaded as split(line, 5).
Hackz0r5001,2012-12-31 12:15:09 CEST,Dinnerbone,Forever,For being unoriginal, I mean really!
Hackz0r5000,2012-12-31 12:13:14 CEST,Dinnerbone,2013:01:01 00:00:00 CEST,Being an ultimate badass hacker

#Old formats will be converted as the following:
OldMan,Unknown,Unknown,Forever,Banned by an operator.

#Name field is the person who is banned. Case insensitive.

#Date/time field is in the following format: "yyyy-MM-dd HH:mm:ss Z",
# or the literal "Unknown". Any values it doesn't recognize will be "Unknown".

#Banned by field is the operator who banned the player. Empty values will be
# treated as "Unknown".

#Until field is the same format as date/time. If this isn't "Forever" then the
# player will be unbanned at (roughly) the specified time. Unknown values are
# treated as "Forever".

#For field is the reason the player was banned. It will be displayed when the
# client tries to join. May contain format codes. Empty defaults to
# "Banned by an operator."

white-list.txt

#Name, Date/Time, Added By, Comment

#All values are trimmed
#<-- these are comments and will be ignored by the parser
#The comment field may contain unescaped commas (, <--). It will be loaded as split(line, 4).
Santa,2012-12-31 12:15:09 CEST,Dinnerbone,He brings me gifts.
ReallyCoolDude,2012-12-31 12:13:14 CEST,Dinnerbone,I like this dude.

#Old formats will be converted as the following:
OldMan,Unknown,Unknown,

#Name field is the person who is white-listed. Case insensitive.

#Date/time field is in the following format: "yyyy-MM-dd HH:mm:ss Z",
# or the literal "Unknown". Any values it doesn't recognize will be "Unknown".

#Added by field is the operator who white-listed the player. Empty values
# will be treated as "Unknown".

#Comment is anything you like. May contain format codes. Empty values allowed.

This is really cool! Looking forward to this!

Whats wrong with using a single whitespace as seperator? None of the fields contain spaces, except the comment which is last.

Concerning the ban lists: I don't know about the backwards compatibility but for usability one file, called banned-players.txt, is better than two in my opinion. Just include a comment in the head of the file with some examples using names and IPs.

@taesheren
Whats wrong with using a single whitespace as seperator? None of the fields contain spaces, except the comment which is last.
Everything. Absolutely everything. A space is way too common of a character to be using as a separator for any reason, ever.
As a matter of fact, the space is so common that the date fields contain two spaces each!
Also, the method that will be used to split the lines will explicitly truncate anything beyond the specified limit. While this limit is optional it would add a lot of needless code to use a space as the delimiter. The "|", Vertical bar, Pipe or whatever you prefer to call it is my preferred delimiter in simple (read: dumb) split functions as it is less likely to be seen in the data than other easily typed delimiters, in my opinion.

This is the function that the line are being split with:
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html#split%28java.lang.CharSequence,%20int%29

Why not use a TAB as a seperator and (maybe) let people use a TSV/CSV parser? And prevent Tabs in comments.

To preserve Comments as extensions for mods isn't easy:

1. List will be stored in another order in memory for performance reasons
2. Peoplw may put normal comments in there which don't belong to an entry
3. Possible Multiple Comment lines in front of an entry makes parsing and saving back complicated.

And I assume you want to completelly rewrite files sometimes or do you just append and read and ignore old entries for temp bans etc. (free history)?

How about letting Mods append as many TAB-seperated values after the comment as they want and recommend this format:
ModName.1.0:XXXXXXXXXXXXX
XXXX cannot include tab, but can be csv or comma separated name/value pairs etc.

Honestly, I think if a plugin wants to store additional metadata about a ban, it should be done elsewhere—and using a more suitable data format. Trying to shoehorn rich metadata into a simple human-editable file is silly.

@erisdiscord
Amen to that.

@ToastedJelly What he said... SQL all the way!

Also, why store it in human readable format at all? Just give admins all of the commands, and store it in a database, where everything should have been stored in the first place. Also, I hope that a suitable replacement for EBean is procured for the official modding api. I don't want to write a lot of SQL code, but I don't want to deal with EBean quirks either.

@zonedabone bans are part of configuration, and configuration and logs are two things that should always be human readable IMO. Relational databases are great for storing relational data.

Representing timezones as strings ("CEST") is a bad idea, because a given string does not uniquely identify a timezone (both Australia and America have an "Eastern Standard Time", for example). Also, time zone definitions can change as laws are passsed. Much better to use the +HH:MM syntax; see "time-offset" in RFC3339.

This is good for a default implementation. What we need however is the ability to replace any component of the engine with our own. For example if we wanted to store the banned playerlist in a database then we would write a plugin with the appropriate component, and get it to override the default implementation. Ofc it could be done with events too, although imo this is far more efficient.

@SamP20 Yes! There should be some system to disable bukkit components in the config and at runtime, and then have enough events to implement it on our own. (Ex. player login events for bans) -Zonedabone

…

On Sat, Apr 21, 2012 at 11:20 AM, samp20 < ***@***.*** > wrote: This is good for a default implementation. What we need however is the ability to replace any component of the engine with our own. For example if we wanted to store the banned playerlist in a database then we would write a plugin with the appropriate component, and get it to override the default implementation. Ofc it could be done with events too, although imo this is far more efficient. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2422512

Wait, so if the ban message contains commas, it won't screw it up? It just looks a bit confusing, though.

@Surfjamaica Nah, the line is split into 5 parts. The ban message is always the last part so no matter how many commas the ban message contains it will be fine. Read this javadoc http://docs.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html#split%28java.lang.CharSequence,%20int%29 It is the very piece that is being used.