61–70 of 73 posts
Why do all these serialization frameworks like protobufs, flatbuffers, capnproto, etc. have bespoke schema languages? Why not just use JSON-based schema so that you don't need custom parsers for it? It would definitely make metaprogramming easier as well.
Earlier quoted context omitted.
Thanks. I wasn't aware that putting a date in the title might violate the guidelines.
It does not. You can see dang, one of the moderators, write: "It's the convention on HN to add the year to a title when the article isn't from this year." at https://news.ycombinator.com/item?id=27867435 , write "On HN, it's the convention to add the year when a story is more than a year and a bit old." at https://news.ycombinator.com/item?id=16306830 and write "It's just the convention to add the year in parens (and…
In retrospect, my original comment was probably too terse. It's not obvious if I was suggesting that "(2019)" be added to the title, or if I was claiming that the article was outdated for some reason. That's my fault.
Rest in peace, Ian, my friend.
RIP zenhack
Earlier quoted context omitted.
Avro uses json for its schema language.
But also has a schema language, and a avro.reflect which can construct schema from java class. Avro schema in Json is very unreadable in my experience. Another bad thing is something like ["int", "null"] gets formatted over 2 lines by standard JSON formatters, making it even harder to read.
Really? I admittedly don't know a whole lot about avro, but everything I've been able to find about avro schemas uses json.
Edit: I found it: https://avro.apache.org/docs/1.11.1/idl-language/
Earlier quoted context omitted.
For context: it seems that the author passed away on last July https://www.winchesteruu.org/2023/07/25/joys-sorrows-and-tra...
"Last" in this context refers to the year. Last July would be July 2022; July 2023 is this July. July 2023 will become last July at the start of 2024.
Earlier quoted context omitted.
> I am not sure what can the serialization framework possibly _do_ to make things secure during the serialization Loads of things! A strict specification that can only be interpreted one way goes very far. E.g.: a machine-readable BNF grammar file or something similar with no ambiguities. A conformance test suite covering corner-cases is surprisingly effective, even with a supposedly perfect spec. "Be strict with wha…
what's the best modern alternative that is designed in this way?
Unfortunately these are lessons that have to be learned over and over. Anything based on JSON is generally suspect. If you see the terms "quick" or "simple" in some marketing splash-page, assume the author has not thought about the hard problems like security and long-term interoperability.
Similarly, if you find yourself hand-rolling RPC client code and calling methods on something like "HttpClient" manually, you've done it wrong. That code should have been spat out by a code-generator from a schema.
Earlier quoted context omitted.
But also has a schema language, and a avro.reflect which can construct schema from java class. Avro schema in Json is very unreadable in my experience. Another bad thing is something like ["int", "null"] gets formatted over 2 lines by standard JSON formatters, making it even harder to read.
> But also has a schema language, Really? I admittedly don't know a whole lot about avro, but everything I've been able to find about avro schemas uses json. Edit: I found it: https://avro.apache.org/docs/1.11.1/idl-language/
But the fact it exists means at least some people find JSON verbose.
Earlier quoted context omitted.
Thanks. I wasn't aware that putting a date in the title might violate the guidelines.
It does not. You can see dang, one of the moderators, write: "It's the convention on HN to add the year to a title when the article isn't from this year." at https://news.ycombinator.com/item?id=27867435 , write "On HN, it's the convention to add the year when a story is more than a year and a bit old." at https://news.ycombinator.com/item?id=16306830 and write "It's just the convention to add the year in parens (and…
Earlier quoted context omitted.
Users are not advised to do this themselves. The submission guidelines contain no such allowance. They specify a very limited set of cases where the title of a submission can be modified from the web page title.
This is a long-established convention to include the year if the article is a year and a bit old. See dang, one of the moderators, affirm this multiple times at https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... , most recently 17 days ago.
Earlier quoted context omitted.
> Serialization and parsing are security minefields and it is dangerously naive to just hand-wave that away. well, i am not hand-waving them away, i am not sure what can the serialization framework possibly _do_ to make things secure during the serialization ? when execution of user-supplied code is allowed (in the examples that you have outlined above), surely, the layer _executing_ the code cannot really do anythin…
> I am not sure what can the serialization framework possibly _do_ to make things secure during the serialization Loads of things! A strict specification that can only be interpreted one way goes very far. E.g.: a machine-readable BNF grammar file or something similar with no ambiguities. A conformance test suite covering corner-cases is surprisingly effective, even with a supposedly perfect spec. "Be strict with wha…
>> Loads of things!
>> A strict specification that can only be interpreted one way goes very far. E.g.: a machine-readable BNF grammar file or something similar with no ambiguities.
once again, that is not the domain of the serialization framework ! it is a policy which needs to be established and enforced at input / output layer by the entity which implements it.
a serialization framework should just serialize and deserialize objects to / from an i/o 'channel' f.e. file, network, etc. shackling it with specification / enforcement of security etc. policies seems conflating one concern with another.