Configuration serialization should use a single representation.

[theSloopJohnB]

The serialization scheme right now uses a mix of json and xml. The json is used to represent the hierarchy of the nodes, but xml is used to represent the data within the nodes.

This scheme makes reading the configuration file painful.

Any changes should be backward compatible, both so in flight projects can take advantage of the change and so we don't break projects on updating to newer versions.

[tannerblair]

I've been working on a DOM-based JSON library with Milan Raj that is a lot more flexible than the native solution. If you decide to move the config to JSON, I would recommend checking it out. It makes it much easier to manage JSON that may change.

https://github.com/rajsite/i3-json

[theSloopJohnB]

Thanks for the tip. I see that the tools network hasn't seen a release in over a year with any of your recent commits. Are you or Milan planning on releasing an updated VIPB soon?

[tannerblair]

Yeah, there are a few other features I was hoping to implement, namely better array handling on parse and some bug squashing with the error handling. I've gotten sucked in to a few other things, but if you think you might want to use it I can bump it up the priority queue.

[theSloopJohnB]

I’ll let you know if we decide to implement this feature in the short term. If we did start work on it in the short term, I could begin using the library while you’re still working on improving the internals of it, so long as we coordinate publishing to VIPM. From: Tanner Blair [mailto:[email protected]] Sent: Friday, July 21, 2017 1:14 PM To: NISystemsEngineering/CEF <[email protected]> Cc: John Boyd <[email protected]>; Author <[email protected]> Subject: Re: [NISystemsEngineering/CEF] Configuration serialization should use a single representation. (#92) Yeah, there are a few other features I was hoping to implement, namely better array handling on parse and some bug squashing with the error handling. I've gotten sucked in to a few other things, but if you think you might want to use it I can bump it up the priority queue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_NISystemsEngineering_CEF_issues_92-23issuecomment-2D317074213&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=sRRaQ6J45Tg6TDxQFmZR6g&m=ebGSjWepdkbIh3e-J_NZ3ZMalEGR71SbTRDM8xPGuxo&s=Wu5oYw8SZmzgz0ZU733p3LbYkA2uk8oKvApEFn4-sZ8&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AZun2cZRU-5FRmDfdnaly34rVn-5F4YbF5ORks5sQOpvgaJpZM4Ofn4i&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=sRRaQ6J45Tg6TDxQFmZR6g&m=ebGSjWepdkbIh3e-J_NZ3ZMalEGR71SbTRDM8xPGuxo&s=b7746EbzQQbIkRGuauG3c9mxQFM__L2-QTkJPaNbZTM&e=>.

[smithed]

What would be the advantage of the i3 json library as compared to any of these?
https://bitbucket.org/lavag/json-api-labview/downloads/
https://bitbucket.org/drjdpowell/jsontext
https://github.com/JKISoftware/JKI-JSON-Serialization
A quick glance seems to indicate that the i3 version is almost identical in principle to the lava version, drjdpowell's was built to overcome some performance limitations in that style, and the jki version seems to be "flatten to json, but done by people who use it"

With regards to the broader issue, fixing this would also resolve #80 as they are related (that issue focuses on making the module data be more sane and standard, rather than the scheme I came up with for performance (I dont think there was an issue for the original format because it was new, the index based implementation is here: LabVIEW-DCAF/TagEditorCore#24)

[tannerblair]

I personally prefer i3 because it's wrapped better, is less verbose, and the wire in i3 is a variant so it's much easier to troubleshoot when there's a problem. The variant is also much easier to extend when it doesn't quite do what you want, and it allows for the ability to query a parsed structure to see what keys are present rather than having to know the name of all keys in advance.

There are also some nice functions for visualizing the data in a JSON tree, so you can go way beyond prettyprint when wanting to look at what's in a JSON Object created with this:

It's also written and maintained in LV 2014, so it's compatible with every LV version that DCAF supports.
jsontext is written in 2017 and uses VIMs, so can't be saved for previous.

It also has 0 dependencies, whereas JKI and LAVA both have dependencies on 4 or so OpenG libraries.

Also, all of our other JSON-based applications in SE are moving towards this so from a maintenance standpoint it would be nice to not splinter what JSON API we're using.

[smithed]

None of those seem like particularly great points for building yet another json library, but ok. You should read through this article http://seriot.ch/parsing_json.php and try not to fail as hard as the other json parsers of the world.

With the tree functions I don't know if you used this as a baseline, but it might be good to compare notes with https://lavag.org/files/file/19-variant-probe/

[tannerblair]

To be clear, I didn't make this and I'm not making this. Milan Raj did. It's existed for 5 or so years now, I'm just helping to document and extend it.