Configuration serialization should use a single representation. about cef HOT 8 OPEN

from cef.

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

from cef.

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?

from cef.

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.

from cef.

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)

from cef.

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.

from cef.

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/

from cef.

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.

from cef.