Standards/Consortia: OpenDocument, Asciidoc, and HTTP/3
-
How ODT files are structured
Word processing files used to be closed, proprietary formats. In some older word processors, the document file was essentially a memory dump from the word processor. While this made for faster loading of the document into the word processor, it also made the document file format an opaque mess.
Around 2005, the Organization for the Advancement of Structured Information Standards (OASIS) group defined an open format for office documents of all types, the Open Document Format for Office Applications (ODF). You may also see ODF referred to as simply "OpenDocument Format" because it is an open standard based on the OpenOffice.org's XML file specification. ODF includes several file types, including ODT for OpenDocument Text documents. There's a lot to explore in an ODT file, and it starts with a zip file.
-
Try Asciidoc instead of Markdown
I'm a happy user of the XML-based Docbook markup language. To me, it's a precise, explicit, and detailed system that allows me to have contextual and domain-specific metadata in what I write. Best of all, though, it can be transformed (that's what XML users call it when XML is converted into another format) into nearly any format, including HTML, EPUB, FO for PDF, plain text, and more. With great power comes a lot of typing, though, and sometimes Docbook feels like it's surplus to requirements. Luckily, there's Asciidoc, a system of writing plain text with the same markup-less feel of Markdown, but that transforms to Docbook to take advantage of its precision and flexibility.
-
QUIC and HTTP/3 with wolfSSL | daniel.haxx.se
Back in the summer of 2020 I blogged about QUIC support coming in wolfSSL. That work never actually took off, primarily I believe because the team kept busy with other projects and tasks that had more customer focus and interest and yeah, there was not really any noticeable customer demand for QUIC with wolfSSL.
Time passed.
On July 21 2022, Stefan Eissing submitted his work on introducing a QUIC API and after reviews and updates, it was merged into the wolfSSL master branch on August 9th.
The QUIC API is planned to appear “for real” in a coming wolfSSL release version. Until then, we can play with what is available in git.
Let me be clear here: the good people at wolfSSL has not decided to write a full QUIC implementation, because that would be insane when there already exist so many good existing alternatives being made. This is just a set of new functions to allow wolfSSL to be used as TLS component when a QUIC stack is created.
Having QUIC support in wolfSSL is just one (but important) step along the way as it makes it possible to use wolfSSL to build a QUIC implementation but there are some more steps needed to turn this baby into full HTTP/3.