Persistent JSON storage

[Orbiter]

we need a json file storage options to store settings in json objects

• create a class "JSONFile" in https://github.com/loklak/loklak_server/tree/master/src/org/loklak/tools/storage
• the class must extend JSONObject
• the class must have an initializer JSONFile(File file) wich reads (if exists) or creates (if not) the json file upon call
• the class must overwrite the 'put' method and re-write the json file every time an update is made
• same with delete

This is a naive way to do that, but it will do the job

[Orbiter]

@shivenmian please join in

[rmader]

@Orbiter I was busy with #384 today, will start on this tomorrow or monday

[shivenmian]

Okay so @Orbiter, for storage per se, this does look like a nice idea which can be implemented, but I want to ask: we're gonna use this for storing the public / private keys right? And they will be used to encrypt the passwords the user fill when they fill the sign-up form? Just to be clear.

[rmader]

If I get this right, the overall direction is what's discussed in #353 (see also #375)
So this does not have to do with the login of users in the first place, but rather of indentifying other loklak peers.

But maybe we should think this together with the login mechanism, as we could grant known loklak peers special previleges on certain apis (allowing login either by username/password or a challange as described by #377 )
I'd love to see the user/trust management to share as much code as possible

@Orbiter is ok if we start with the login mechanism #363 to have that finished up and then come back on this whole batch of issues?

[Orbiter]

@shivenmian #373 (comment) no
@treba123 this is part of something else and there is no need for queueing

[rmader]

@shivenmian I created a class for this, could you have a look and help me testing if you have time?
@Orbiter Right, I confused that with the other issues which were related to private/public keys (which @shivenmian was probably refering to)

[shivenmian]

Sure. Link?

[rmader]

Ah right, here

[shivenmian]

@treba123 I haven't pulled your code because I'm facing some weird problems in my build, which I am fixing. But I've checked your code and it looks fine to me. You seem to have covered all the datatypes that should be used.

Do you want me to test something specifically?

[rmader]

Hm I just did some testing it seems to run all fine. I guess it's alright.
I just wanted some more eyes to have a look if i forgot something

@Orbiter does this need to save for multiple uses? Because right now, if one file is opened multiple times, they all have a own instance of the object in memory and overwrite each other.
Is that ok or do you want them to always read from disk? (probably slow), as for each operation they'd have to reread data from disk.

Or should there be a file (write) lock?

[rmader]

For #374 we only have one instance each, so I guess i'll leave locks for later

[rmader]

merged #405