4 ms·

> you can tell it was designed before XML/JSON were "hot or you can tell it was designed by people who care more about performance.

dspillett 2y ago
> > you can tell it was designed before XML/JSON were "hot > or you can tell it was designed by people who care more about performance. I doubt parsing iCal is significantly more performant than JSON for most use cases. In fact I can image it being less so in more cases than it is more so, and as close to the same as makes no odds in the vast majority of cases.
- LeonB 2y ago
  Parsing iCal was far more performant than parsing JSON as your parser could simply start at the first byte, and follow the spec — whereas a JSON parser would first need to wait for ten years before JSON was invented.
  - dspillett 2y ago
    The original comment implied that parsing JSON was less efficient (either in terms of coding required, or the resulting CPU use) than parsing iCal. While it is true that dealing with json by hand is going to be more work than just importing an iCal library, I'm comparing apples to apples and suggesting dealing with json "by hand" is no more faff than dealing with iCal "by hand", and that dealing with either via a good library equally gives no benefit to iCal.
    - sleepyhead 2y ago
      Most data formats used in high performant scenarios, for example in finance, are very basic for a reason. You also get the benefit of being able to start processing the file immediately line by line, instead of having to read and parse the entire file.
canucker2016 2y ago
the iCalendar rfc shows nov 1998 - https://www.rfc-editor.org/rfc/rfc2445 https://www.rfc-editor.org/rfc/rfc2445 iCalendar is based on vCalendar, http://www.imc.org/pdi/vcal-10.txt http://www.imc.org/pdi/vcal-10.txt - need to go to archive.org to see it, which shows Sept 1996. from wikipedia, XML is listed as first published in Feb 1998, JSON is early 2000s. edit: XML'd iCalendar, 2011 - https://datatracker.ietf.org/doc/html/rfc6321 https://datatracker.ietf.org/doc/html/rfc6321 JSON'd iCalendar, 2014 - https://datatracker.ietf.org/doc/html/rfc7265 https://datatracker.ietf.org/doc/html/rfc7265

dspillett 2y ago

> > you can tell it was designed before XML/JSON were "hot > or you can tell it was designed by people who care more about performance. I doubt parsing iCal is significantly more performant than JSON for most use cases. In fact I can image it being less so in more cases than it is more so, and as close to the same as makes no odds in the vast majority of cases.

LeonB 2y ago
Parsing iCal was far more performant than parsing JSON as your parser could simply start at the first byte, and follow the spec — whereas a JSON parser would first need to wait for ten years before JSON was invented.
- dspillett 2y ago
  The original comment implied that parsing JSON was less efficient (either in terms of coding required, or the resulting CPU use) than parsing iCal. While it is true that dealing with json by hand is going to be more work than just importing an iCal library, I'm comparing apples to apples and suggesting dealing with json "by hand" is no more faff than dealing with iCal "by hand", and that dealing with either via a good library equally gives no benefit to iCal.
  - sleepyhead 2y ago
    Most data formats used in high performant scenarios, for example in finance, are very basic for a reason. You also get the benefit of being able to start processing the file immediately line by line, instead of having to read and parse the entire file.

canucker2016 2y ago

the iCalendar rfc shows nov 1998 - https://www.rfc-editor.org/rfc/rfc2445 https://www.rfc-editor.org/rfc/rfc2445 iCalendar is based on vCalendar, http://www.imc.org/pdi/vcal-10.txt http://www.imc.org/pdi/vcal-10.txt - need to go to archive.org to see it, which shows Sept 1996. from wikipedia, XML is listed as first published in Feb 1998, JSON is early 2000s. edit: XML'd iCalendar, 2011 - https://datatracker.ietf.org/doc/html/rfc6321 https://datatracker.ietf.org/doc/html/rfc6321 JSON'd iCalendar, 2014 - https://datatracker.ietf.org/doc/html/rfc7265 https://datatracker.ietf.org/doc/html/rfc7265