4 ms·

>What would it look like to have a thriving ecosystem of third-party clients for Google Docs style word processing, which can all interoperate with each other,

by jasode 6y ago

>What would it look like to have a thriving ecosystem of third-party clients for Google Docs style word processing, which can all interoperate with each other, even supporting realtime collaboration? Well, based on decades of history of other complex file formats such as pdf, zip, and MS Office formats of doc, docx, xls, xlsx, etc... it would be a buggy mess. It didn't matter whether the format was reverse-engineered or an officially open specification. The issue is that a plain text file used for programming code is linear from top to bottom and so the low complexity for universal editors is just parsing CR/LF to interpret lines. (Yes, there can be extra complexity of syntax highlighting but the base level complexity of opening the file for display is still just parsing CR/LF.) The complexity is higher for pdf/zip/xls because a common theme is each have a internal hashmap/dictionary/directory that has byte pointers backwards and forwards to other parts of the file. And they have internal hierarchies of data structures. And changing from binary representation to XML such as Microsoft's OOXML doesn't change the base complexity which is why LibreOffice has constant bug reports from users unable to open their particular docx/xlsx file. When I collaborate with others in MS Word/Excel, a best practice is to make sure everybody is using the same version of MS Office. If somebody is using MS Office 2007 while others are on Office 2013, a roundtrip save & open between different versions will eventually corrupt the file or lose data. Even staying with just one vendor like MS can get unreliable. The wild west has lots of utilities/libraries that write incorrect zip files and broken pdf files. >Some successful existing examples of client ecosystems built around open standards: [...] email clients I'm not totally sold on this example. Yes, the open standard is SMTP for network communication... but there's another aspect that isn't standard: the on-disk file format for email archives. Microsoft Outlook uses binary PST files but Mozilla Thunderbird uses text-based MBOX files. But Mozilla's MBOX is slightly different from other tools that use MBOX.

swiley 6y ago
Maybe collaborate using markdown with stylesheets instead of word then. As for the mbox problem: on a normal machine that must be shared between multiple tools (at the very least: biff,lmptpd, and the MUA) if thunderbird can't interoperate that's a serious bug.
- Arainach 6y ago
  "Give up all of these cool features because it's 'open'" isn't a winning argument with any consumer. WYSIWIG rich-text documents are table stakes. Users have had them for 30 years, love them, and are never giving them up. Their layout (and thus their schema) are also incredibly complex by necessity.
- oblio 6y ago
  Markdown is both underspecified and underpowered as a markup language.
  - KouAkitaki 6y ago
    There's the CommonMark spec: https://spec.commonmark.org/ https://spec.commonmark.org/ It's still an underpowered language though.
dcposch 6y ago
> Some successful existing examples of client ecosystems built around open standards: [...] email clients Yeah, the way they just casually slid that in there... That example really cuts both ways. Yes, email is fundamentally better than other messaging formats in one respect. Standardization gives it permanence and universality. There are many things we use email for where it would be absurd to use anything else. But when you actually lift the cover on email, it is a crusty box full of hornets and spiderwebs. The actual, in-practice email standard comprises: - A weird, undocumented and ancient subset of HTML - A weird, undocumented and ancient subset of CSS - A motley assortment of supported attachment types. Multipart MIME. For the main message body, you can use any type you want as long as it's `text/html` - A ton of headers. Did you know that SMTP FROM and the From line we all know and love are two different headers? Often containing two different addresses! Don't even look at threading/References/In-Reply-To, it will make you sad. - And, of course, a bunch of overlapping bandaids to try to retroactively add authentication. DKIM, SPF, DMARC etc. It is so bad that there's a whole ecosystem of companies that try to make it less painful, often with very brute-force approaches. I once had to use an expensive tool called Litmus. They literally just run VMs for every OS + mail client combo, then show you how your email will render in each case. Haha try again, your CSS is broken on Win7 / Outlook 2013. -- The same underlying facts that make it a great format as a user make it obnoxious as a developer.

by jasode 6y ago

swiley 6y ago

Maybe collaborate using markdown with stylesheets instead of word then. As for the mbox problem: on a normal machine that must be shared between multiple tools (at the very least: biff,lmptpd, and the MUA) if thunderbird can't interoperate that's a serious bug.

Arainach 6y ago
"Give up all of these cool features because it's 'open'" isn't a winning argument with any consumer. WYSIWIG rich-text documents are table stakes. Users have had them for 30 years, love them, and are never giving them up. Their layout (and thus their schema) are also incredibly complex by necessity.
oblio 6y ago
Markdown is both underspecified and underpowered as a markup language.
- KouAkitaki 6y ago
  There's the CommonMark spec: https://spec.commonmark.org/ https://spec.commonmark.org/ It's still an underpowered language though.

dcposch 6y ago

> Some successful existing examples of client ecosystems built around open standards: [...] email clients Yeah, the way they just casually slid that in there... That example really cuts both ways. Yes, email is fundamentally better than other messaging formats in one respect. Standardization gives it permanence and universality. There are many things we use email for where it would be absurd to use anything else. But when you actually lift the cover on email, it is a crusty box full of hornets and spiderwebs. The actual, in-practice email standard comprises: - A weird, undocumented and ancient subset of HTML - A weird, undocumented and ancient subset of CSS - A motley assortment of supported attachment types. Multipart MIME. For the main message body, you can use any type you want as long as it's `text/html` - A ton of headers. Did you know that SMTP FROM and the From line we all know and love are two different headers? Often containing two different addresses! Don't even look at threading/References/In-Reply-To, it will make you sad. - And, of course, a bunch of overlapping bandaids to try to retroactively add authentication. DKIM, SPF, DMARC etc. It is so bad that there's a whole ecosystem of companies that try to make it less painful, often with very brute-force approaches. I once had to use an expensive tool called Litmus. They literally just run VMs for every OS + mail client combo, then show you how your email will render in each case. Haha try again, your CSS is broken on Win7 / Outlook 2013. -- The same underlying facts that make it a great format as a user make it obnoxious as a developer.