JSON as an Application's File Format?
JSON as an Application's File Format?
My mapping application can save a data file to disk (as do most applications). I simply stream the objects, compress the stream and save it to a file. The problem with this approach is the file format changes whenever I add a new field to an object. I can handle newer versions opening older formats but it's a pain when an older version cannot open a file created with the most recent version.
My question is, would saving the data in a JSON format potentially solve this problem?
As I understand it, JSON is a text format based around a flexible dictionary-type structure i.e. pairs of keys and values. Let's assume I initiate all objects with default values. As the file is parsed it will look for a key for each property and return the corresponding value. It doesn't seem as if it would be a problem if there was a key in the file that wasn't used by the (older) version of the application. This would provide forward and backward file compatibility. Have I got this right? Has anyone else tried doing this?
Thanks - Steve
My mapping application can save a data file to disk (as do most applications). I simply stream the objects, compress the stream and save it to a file. The problem with this approach is the file format changes whenever I add a new field to an object. I can handle newer versions opening older formats but it's a pain when an older version cannot open a file created with the most recent version.
My question is, would saving the data in a JSON format potentially solve this problem?
As I understand it, JSON is a text format based around a flexible dictionary-type structure i.e. pairs of keys and values. Let's assume I initiate all objects with default values. As the file is parsed it will look for a key for each property and return the corresponding value. It doesn't seem as if it would be a problem if there was a key in the file that wasn't used by the (older) version of the application. This would provide forward and backward file compatibility. Have I got this right? Has anyone else tried doing this?
Thanks - Steve
We have done this for a Application from us 2 years ago I think, should work.
ReplyDeleteYes, I have been using JSON as storage for years. It seems to solve practically all backward/forward compatibility issues.
ReplyDeleteit's not a file format question, it's a parser issue...DFM also can have new properties :)
ReplyDeletePaul TOTH I use the Mitov.Runtime for that. It can parse and store retrieve all the properties of forms etc. and much more, everring way more than what the traditional DFM can do, and much easier ;-)
ReplyDeleteBoth Visuino and OpenWire Studio use JSON now instead of the DFM they used in the older versions.
Paul TOTH I have been adding a lot of new features lately to the Mitov.Runtime JSON support and serialization. Trying to post another release in few days on my blog, and hopefully when the main site gets updated there too...
ReplyDeleteBoian Mitov I don't use DFM to store custom data...But I have to disagree with you, JSON has poor habilities to store many things, from binary data to just a simple Date; there's no standard about that.
ReplyDeletePaul TOTH I store binary data and everything else. Works for me ;-) . Since the storage is used by my applications, I have established my own standards whenever one did not exist ;-)
ReplyDeletePaul TOTH BTW: The Mitov.Runtime parser handles both cases of missing and new properties when serializing. It also has support for remapping properties that have been renamed, changed to different type or moved to sub properties etc.
ReplyDelete