Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Data storage format #32
Edit: Updated to reflect the current state of HashOver's support for different data storage formats. Serialized PHP is no longer being considered.
It seems advantageous to move away from XML as HashOver's default data storage format. The following is a list of considerable replacements. Any formats that require additional libraries or installation and/or configuration of server-side software (ie. MySQL) to employ or that are only available in PHP versions higher than 5.3, aren't being considered.
I won't use a database for the sake of using a database, most of the data formats below have more benefits within the context of HashOver than a database provides. The only benefit databases provide is a secure way to store password hash salts, but it is recommended that the comment files have no public read, write, nor execute permissions, thus securing the files just as significantly.
I'm considering the following things: human-readability, compatibility, speed, character set support, and interoperability. I will only use the format that best satisfies these conditions.
SQLite is well supported by PHP, it's a very well known data storage format, and unlike MySQL and many other *SQLs, SQLite doesn't require configuration of server-side software. PHP creates a file with a
Support custom data format classes
Similar to how the
What is needed here is documentation about how to write a proper data format class for HashOver, and a template from which a developer may base their class.
If anyone has recommendations, please feel free to comment here or open specific issues. It is likely that all of the above data formats will be supported upon release, with an additional option in the settings for choosing between them, in such a case the question of data formats becomes:
"Which should be the default?"
Just so I understand what's not considered, something like this is out of the question?
In any case, I've been reading previously on XML and JSON... From what I gathered, we would need to be more careful with JSON when it comes to security, some interesting points raised here
Protocol Buffers is definitely not out of the question, I really like the overall idea of it. However, Protocol Buffers don't seem to be well supported by PHP currently, "not well supported" as in no native way to write or parse .proto files. Third-party libraries would be required, and I am not willing to delegate such an important task to third-party libraries, thus my similar opposition to jQuery.
Many of the libraries aren't actively developed either.
Developing a custom reader, parser and writer is possible, but that's a job best left to the developers of PHP itself. Overall, Protocol Buffers seems to be a possible JSON successor, and will more than likely eventually have proper native support in PHP, when that happens it will be a serious consideration, however, it would also mean increasing the minimum PHP version to whatever version gets the support first, which is undesirable.
Having it as an optional storage format isn't out of the question, either.
I launched my website just as you updated the storage formats... am now considering whether to stick with xml or switch to json before comments start to pop.
Any drawbacks you have found with json?
The size benefits aren't that big but it's still something I appreciate.
Though, JSON's main security issues seem to be related to
Unrelated to JSON: Just to be safe, you might want to make sure people can't view anything under
a few comments from my side:
i can work on patch for getting all the comments in one single file per page and for defining the target path for the those files.