On Tue, 27 Mar 2012 09:22:30 -0500 Andy Doan andy.doan@linaro.org wrote:
On 03/27/2012 06:32 AM, Paul Sokolovsky wrote:
So, I would like to propose alternative syntax solving the issues above. I probably should start with saying that if the talk is about LAVA, then using native LAVA JSON request immediately comes to mind. Well, I guess human-writability wasn't a design goal for that, so I skip it. It still makes sense to stick to general-purpose hierarchical structure syntax though. Except that JSON has 2 problems: a) it doesn't support comments natively, so we'll need to pre-process
I'm fine with the overall idea, but I'm not a big fan of adding support for comments for two reasons.
- are these files really so exotic they need comments. ie:
Well, don't even let me start to rant how stupid was for JSON founding fathers to explicitly exclude comment support ;-). My logic though would be very simple: it's human readable, so excluding humans from its processors was really unwise. Well, even CPU vendors include NOP in instruction sets, not saying that "LD A,A" or "JMP $+N" should be enough for fillers.
# run monkey { "commands": [ "monkey 2000"], } I don't see those type of comments as useful
How about:
# We run 1000 iterations above - that must complete successfully for # build to be good. Let's now run 2000 iterations as additional optional # test of build stability.
?
- if comments are needed couldn't we work around it and still be
valid JSON by doing something like:
{ "comment": "Let's pretend this is useful", "commands": [ "monkey 2000"], }
Well, I don't know about other folks, but 80% of my comment usage is not to add human-readable textual notes, but to temporarily disable some code/data, to be re-enabled later.
That said, I'm not the one who'd be writing those tests, so if folks who are target audience of this feature can testify they don't need meta-syntax comments, then well... On the other hand, supporting them is one preprocessing call to re.sub(), so no implementation chore. Methodologically, we can just consider that we're using "Extended JSON", it's certainly better for this case than inventing adhoc syntax or using XML.