Description
Make the configuration data more readable, simple and easy to handle.
Use case or motivation behind the feature request
Right now, all the configs, data and results are combined in one gigantic JSON object. This object is send in bulk and then dissected, distributed and recombined in the code, causing a lot of complications and obscurity. To commit any simple change to anything, being paragraph data, any paragraph or result setting, the JSON file needs to be recombined and sent to the server again, and then received again as confirmation.
paragraph data split.pdf
Current suggestion is to split the JSON object into 4 smaller and more specialized and to deliver them to correct locations separately.
Description Make the configuration data more readable, simple and easy to handle.
Use case or motivation behind the feature request Right now, all the configs, data and results are combined in one gigantic JSON object. This object is send in bulk and then dissected, distributed and recombined in the code, causing a lot of complications and obscurity. To commit any simple change to anything, being paragraph data, any paragraph or result setting, the JSON file needs to be recombined and sent to the server again, and then received again as confirmation.
Related issues To make it more efficient, there is a need for better API with more endpoints. which will allow to split the logical fragments and server different purposes.
https://github.com/teragrep/zep_01/issues/17 https://github.com/teragrep/ajs_01/issues/243
Additional context Attached file with detailed analysis on the JSON file and some of its use-cases.
config mindmaps.pdf