131–140 of 153 posts
if you are sending data to "yourself" and performance is important, defining your own binary protocol can be very effective. every time I go to grok protobuf, thrift, et al. I end up just rolling my own format because it's so much simpler and I can take all the tradeoffs that benefit what I'm doing instead of what anyone might possibly do with it. this doesn't apply in many situations (i.e. sending data to outside pa…
I find it curious that serialization formats like JSON get hit on for not having a native date/time format. Just use a UNIX timestamp and be done with it.
https://tools.ietf.org/html/rfc7493 says to use an ISO 8601/RFC 3339 timestamp, uppercase, with timezone, with seconds. IOW, Javascript's toISOString() or equivalent.
Just to be a broken record: JavaScript is better than JSON because it has loops, conditionals, comments, modules, functional programs, typing, etc etc
Earlier quoted context omitted.
https://tools.ietf.org/html/rfc7493 says to use an ISO 8601/RFC 3339 timestamp, uppercase, with timezone, with seconds. IOW, Javascript's toISOString() or equivalent.
You need to parse that. For graphs with thousands of data points just use Unix time plus a timezone or use the browser's timezone. ISO 8601 would leave your graphs churning for seconds.
From an aesthetic point-of-view, XML is ideal. It reads like S-expressions or Lisp but with enough features to be a robust serialization format or even represent code. Validation alone puts it ahead of JSON. Too verbose? What kind of editor are you using that can't add the closing tag automatically or show you validation errors as you go. If type checking is good, then XML is good.
The main reason XML is hated now is that it's too difficult to learn.
People that care about performance will use protobufs/capnproto, which has all the safety of XML and more. People that want something to work out of the box everywhere without too much thought will use JSON. There is no room for caring about correctness for its own sake.
> Apache is the tragic junkyard of open source projects This made me laugh more than it probably should have.
The kiss of death. It's a graveyard of things from a previous era, pure maintenance mode. I think library authors get tired of maintaining for free then hand it off to these life support organizations. The new way for open source software is a decentralized ecosystem where people fix software they actually use, so the cream rises to the top on its own and you don't need the sponsorship of these digital museums.
On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not sure it’s something anyone > actually wants to use, it’s just going to be one more of > those mistakes of the past. Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes,…
It's a shame the original article didn't mention XPath which is a great feature when you're in the XML ecosystem. (Obviously JSON has jq, but that's not a standard - so there's no library version - and has some weirdness compared to XPath).