Open apaikan opened 9 years ago
Just my opinion: if we need something easy (and fast) to parse and lightweight (from the point of view of bandwidth) then JSON is a good choice. If we want to be robust then XML (with XSD validation) is a better choice.
@francesco-romano We are using XML in many places in Yarp and its advantage over introducing a new format is that we don't need to deal with a new parser. But XML and JSON are slightly targeting different use cases. JSON also supports Metadata and Schema for validation. Let take an example (passing parameter to the portmonitor carrier) and see which one is more comfortable for the users:
yarp connect /out /in tcp+recv.portmonitor+type.lua+context.myapp+file.my_lua_script
yarp connect /out /in '{"carrier" : "tcp"}, {"recv" : "portmonitor", "type" : "lua", "context" : "myapp", "file" : "my_lua_script.lua"}'
yarp connect /out /in '{carrier : tcp}, {recv : portmonitor, type : lua, context : myapp, file : my_lua_script.lua}'
yarp connect /out /in '<carrier>tcp</carrier> <recv>portmonitor</recv> <type>lua</type> <context>myapp</context> <file>my_lua_script.lua</file>'
The problem with our current format is that it does not allowed grouping, white spaces, quotations and etc. One thing that we have had in mind for long time was to chain the carrier modifiers: the output of a carrier modifier is given to another one and so on. This probably needs a syntax which support the hierarchy of data representation (e.g, as josn or xml does)
However, different formats can be used interchangeably in different places. For example, the carrier parameters can be written in XML format and loaded by yarpmanager which translates it into a yarp::os::Bottle
or yarp::os::Property
and is passed over the yarp network.
Or carrier parameters can be given in JSON format to the yarp connect
command which will be again translated into one of the above yarp object. @paulfitz possible?
@apaikan I completely agree with you. I didn't know about the JSON schema, maybe because it is still a draft. But I think this feature can solve one of the main limitation of the (current - not draft) state of JSON.
And of course in you example XML simply is not the correct choice. I was thinking more of its use in configuration file or not-bandwith critical remove service calls.
I just found this library, it is just headers and cross-platform. It might be worth considering it: http://www.codeproject.com/Articles/856277/ESJ-Extremely-Simple-JSON-for-Cplusplus https://github.com/g40/esj
As it emerged during discussions with @drdanz, @S-Dafarra and @GiulioRomualdi , also https://github.com/toml-lang/toml could be another well established (it is used in Julia and Rust package managers, for example) file format that is quite readable and quite similar to our existing .ini file that could be consider to be supported for loading in yarp::os::Property
.
As it emerged during discussions with @drdanz, @S-Dafarra and @GiulioRomualdi , also https://github.com/toml-lang/toml could be another well established (it is used in Julia and Rust package managers, for example) file format that is quite readable and quite similar to our existing .ini file that could be consider to be supported for loading in
yarp::os::Property
.
Update from the future, in BLF we are using it as a configuration file kind of "side by side" with existing YARP .ini file, and I think it is working relatively fine, related links:
This is a feature request and some brain storming to exploit better the JSON in Yarp. JSON is already used in Yarp for calling RPC command using HTTP carrier. I found this feature very helpful and i think there should be more place in Yarp to benefit from JSON.
1) Using JSON format for passing carrier parameters instead of parsing a home-brew string. 2) ? 3) ?