[Yarnage]

>How does that follow? Usually "data", 5.23423, needs commenting more than most. What the hell is that? Why 5 decimal places?

You would already know the answer before seeing the JSON file so I'm not sure why you care.

For instance, you're not going to be receiving JSON data over email and then putting it into a system manually. Instead, you'll have APIs that handle the JSON formats for you and simply ingest the data.

If you're processing a large volume of data using JSON as the interchange format, why on Earth would you want it to include comments? No service on Earth does this that has any volume of users.

>Also comments in config files are for many things; when file was created, change history, by whom, who to contact with problems, warnings not to edit as it's managed via chef/puppet.

This is not the job of a comment. These go stale and all are available via whatever version control mechanism. However, keep in mind you're talking a very specific edge case in a development environment. Typically these don't matter, at all. If you need comments within the dev system for whatever reason, you can just strip them out. Puppet would obviously have appropriate permissions so no one can simply modify them anyway without knowing they're messing with puppet.

Shipping items, however, should simply have documentation regarding what configurations you product does or does not support.

[roel_v]

Sounds like you're making an awful lot of assumptions about other people's workflows and how they 'should' do things. Have you ever actually worked in a production environment? (no way to ask this without sounding snarky, it's not meant to be mean-spirited)

[Yarnage]

I made no assumptions and there is no need to be rude with your incredibly vague question. There are obviously better ways of asking and I'm sure you knew that (otherwise you would have asked a specific question).

[roel_v]

What's vague about the question? I'm not sure how I can be more specific: have you actually ever worked in a production environment? The point being that the things you sum up sound very much like textbook-knowledge and theory, and nothing like something somebody who has actually, you know, worked with software to get things done (as opposed to just playing around) would say.

[Yarnage]

>What's vague about the question?

You asked nothing relevant to the conversation. Instead you asked about me ever working in a production environment and nothing more.

That questions accomplishes nothing but being insulting. I hate to sound crass but you're acting like an ass.

If you wish to bring something topical and relevant to the conversation then by all means do so but insulting someone gets nothing accomplished other than trolling...in which case you already won. Congrats.

>The point being that the things you sum up sound very much like textbook-knowledge and theory

No, they don't. Everything I stated is from real-world experience. I cannot fathom what kind of environment you work in where service to service communication includes comments going over the wire. But, as you can see above in my other responses, I've already covered all of these aspects. Nothing theoretical.

[nknight]

I'm forced to wonder from your comments throughout this thread whether you have much real-world development experience, versus having just ingested a bunch of theoretical information on best practices. The things you're dismissing out of hand happen all the time, and while sometimes they're useless, more often they're all the documentation you'll get, and you'll feel exceedingly lucky to get even them.

Your comment about Puppet is especially troubling. Puppet doesn't "have appropriate permissions", it's a root-level tool for managing system state. The files it manages may have all kinds of ownership and permissions, some of which are not ones you can just mess with (e.g. the system will throw up its hands and bomb out if they're wrong), and all of which are still modifiable by anyone with root access. There's no way to differentiate short of comments in the files themselves.

[Yarnage]

>I'm forced to wonder from your comments throughout this thread whether you have much real-world development experience, versus having just ingested a bunch of theoretical information on best practices. The things you're dismissing out of hand happen all the time, and while sometimes they're useless, more often they're all the documentation you'll get, and you'll feel exceedingly lucky to get even them.

This is highly arrogant comment. There was no need to be rude. I've been developing and working with actual data for over a decade now. Yes, in the real world sometimes comments are transmitted over the line but I'm sure you can agree that isn't a good idea. Yes, many times you don't get good documentation but you make it sound like that's acceptable and anyone who thinks otherwise doesn't have real-world experience.

In all honestly I would expect comments generated from some odd software packages but it's been an incredibly long time since I've seen data transmissions that contain comments. In environments dealing with petabytes of data you can't afford to send comments with every single file.

As for Puppet, I think you misunderstand my point. Yes, it is a root-level tool. That doesn't mean any user should have the same permissions as Puppet. Why wouldn't you simply place configuration files people shouldn't modify in places where they don't have permission but Puppet does? Honestly, I thought that was standard practice.

[nknight]

You can claim all the experience you want, but your statements belie the truth. JSON is in no way limited to raw data interchange, and the files puppet manages cannot be put off to one side in some magical place where root cannot access them. System administrators will always have access to the files no matter where they are or what permissions you have set, and they need to know that the files are being automatically managed. The system also needs to know where to find the files, you can't start randomly moving /etc/fstab around, for example.

[Yarnage]

>You can claim all the experience you want, but your statements belie the truth. JSON is in no way limited to raw data interchange,

I never stated such a thing but that is what it's designed for and the primary use-case for JSON. I would imagine most other cases are edge-cases.

>and the files puppet manages cannot be put off to one side in some magical place where root cannot access them.

No one said to push them off to the "side" or into some "magical place". It's really simple: puppet has permissions to the files, your users do not.

A system administrator worth his salt isn't going to be messing with configuration files any which way and if said administrator has ROOT access then they should already know that's the level where puppet works and they could screw something up.

So I'm not really sure what your point was...

[mryan]

It appears that he is referring to JSON within the limited context of web APIs. The scenarios dismissed as a "very specific edge case in a development environment" appear to crop up all the time when using JSON for something other than APIs - for example, CloudFormation stack templates are written in JSON, and would sorely benefit from some in-line comments.

[Yarnage]

>It appears that he is referring to JSON within the limited context of web APIs.

I was referring to JSON as an interchange format, which is what it is.

Arguably Amazon should have chosen something different for templates but I think that's an issue beyond simple comments and outside the scope of the argument. Regardless, it's hard to image anyone thinking it's a good idea to send comments over the wire especially if the end point is some sort of service.