On 11/17/19 8:57 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
Implementing JSON for boost serialization wouldn't be very hard. I'm surprised that in 15? years no one has done it.
Your second sentence should make you at least question the first one.
The problem is as I already outlined; if you want to support field reordering,
serialization doesn't require reordering. the json reader for serialization only needs to be able to read archives created by the json writer for serialization which specifies the order.
If you don't support field reordering, the format would basically only interoperate with itself, which defeats the purpose of using JSON. You might as well just use the text archive.
Exactly. Which is probably why no one ever bothered to write a JSON archive. Which is exactly the reason that writing an xml version was an unnecessary waste of time. The idea that it's possible to make an "editable archive" with XML or JSON or anything else is fundamentally false. There is no way that one could map in the general case an "edited" archive to a pre-determined C++ data structure. Of course one could conjure up some specific cases where it would be conceivable - but then we be in the C++ committee trap of engaging in a fools errand of trying to implement a general idea by specifying a bunch of special cases. Nothing would be served by going there. If someone wants to make a JSON version of boost serialization that's fine. But don't think that you can make an implementation which is independent of the C++ data structures being serialized. Look to a different model. Ideally one would have parse JSON to some general C++ format which one can then pick through and retrieve what he wants or determine that it's not in there. Another way to think about it is to replace google protocol buffers. The later requires that you make a separate structural syntax which is a pain. But protocol buffers is even more popular than boost serialization. So I think a Boost JSON parser would success. My personal requirements for such a system would be: a) ability to handle unlimited/unterminated data. As data is read in - an event is triggered when a grammatical element is recognized. b) Events are implemented by the users (though the library would provide a bunch of defaults). This provides for infinite flexibility, parallel execution for large datasets. c) Of course such a system could be implemented in a direct, verifiably correct manner with boost spirit. I don't know what the performance implications would be. Boost XML de-serialization has been done by spirit (first version) for 15 years and no one has complained about the speed. Whenever anyone complains about the speed of text based archives it always goes back to the file system - which presumably would be the case with any JSON library. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost