111–120 of 457 posts
Earlier quoted context omitted.
Is there an agreement on whether it’s or pete yet?
Attributes are XML’s foot-gun.
I disagree. Back in the day we used attributes for everything that was key value and inner tags for anything with structure. We also formatted for clarity:
Earlier quoted context omitted.
I'd prefer XML because of the stability of the tools available for it. Recently I was writing a custom static site generator for my website. I started with python and yaml using the pyyaml lib. After two months (don't laugh, I wasn't writing this generator all this time; i had a break) I tested if everything I wrote previously was warking. Pyyaml came at me screaming that they deprecated something and I shouldn't use…
What are the de facto tools for formatting and querying XML files through a CLI? They should be ridiculously simple to install and use.
Earlier quoted context omitted.
> JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Isn't that only solving half the problem? XML is also pretty difficult to read
It's not even the important half. If I have data that I need to send somewhere, and I can create the format for it, that's really easy to do. The problem, every time, is the reverse; receiving some piece of data and trying to figure out what parts of it I care about. Both XML and JSON allow for schema definitions, but in both cases it fundamentally requires me, as a consumer "grokking" what is being sent. And the ver…
For instance, the recent iMessage bugs that project zero announced were because NSCodable serialization tells the deserializer what class should instantiated. Followed by remote code execution (woo!)
Similar problems have occurred with java serialization over the years, the python serialisation thing (that silly name I can’t recall).
I was recently learning swift and was getting frustrated by the verbosity/work for deserialisaing abstract classes when I realized the clunkiness was due to a design that made the deserialise attacker specified objects basically impossible. Obviously you could engineer a solution that would be exploitable but there’s only so much a platform can do to stop developer mistakes.
Earlier quoted context omitted.
Would you say actual YAML does a better job in Ansible over just writing JSON and letting it be parsed as YAML?
Have you tried writing JSON by hand or diffing it in a pull request?
I think the syntax is actually what makes it more human readable, it's still 95% text/numbers just annotated with information that makes it clear what things actually are instead of hiding them behind confusing computer parsing rules nobody is going to think about while reading human-friendly text.
I like the _idea_ of yaml, but: - it's overly complicated in the wrong ways - common/simple use cases aren't supported and require post processing (i.e. Merging block maps/arrays, string interpolation, etc)
fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…
(suggestion) Drop the 4th requirement. Having to close contexts is a VERY good 'sanity check' to see if something is malformed or not. If appending is necessary make the parser handle multiple copies of the namespace and merge them upon output. Unknown keys and sections should also always be copied from input to output (this is how you embed comments).
To clarify the requirement, history could be a JSON array of objects:
[
{"cmd": "git checkout", "when": 1234 },
{"cmd": "vagrant up", "when": 4567 }
]
If you still aren't convinced YAML is terrible, try copying and pasting YAML fragments with a regular text editor. You might end up with valid YAML, but you won't know until the YAML consumer barfs. BTW, all of a sudden XML with DTDs are looking sane again :)
Use the right tool for the job. I use yaml extensively but never in a situation where someone would want to edit it with a regular text processor.
I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…
And we load the config by curling a JSON payload :) ?
Earlier quoted context omitted.
Depends on the XML. When you start mixing in namespaces (like trying to parse Maven pom.xml files in Python), it quickly becomes a mess.
Namespaces are horrible in Python because the Python XML libraries are deficient. They're generally fine in e.g. Java. (Unless you're trying to represent QName typed data, but that's very niche.)