this post was submitted on 30 Jan 2024
371 points (96.3% liked)
Open Source
31236 readers
224 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Completely agree about STL, however, I cannot for the life of me understand why 3MF isn't a binary format.
It has all these big tech companies behind it, and they landed on incredibly short sighted mistake of making the format human readable, instead of providing good tools for reading and modifying the binary format.
Compressing the human readable content is fine for reducing storage size. But de/serializing the XML is going to be at least 3 orders of magnitude slower. Given a sufficiently large file, the difference would be waiting 30 seconds, vs a barely noticeable 0.3 seconds.
What isn’t variant of XML these days? I know, it’s bad but it’s what it is.
XML isn't as common as one would think. It's been steadily decreasing in popularity and use. It's a very verbose format that is suited to enrich a larger set of data, such as HTML documents. For data heavy documents where, it's a particularly bad match, as you end up using as much text for annotation as the data itself.
Using XML for 3MF is IMHO a technical cop-out, where you don't really want to solve it "correctly", so you go with something that is "good enough". With XML, you know it'll be able to encode anything, be human readable, and have existing parsing libraries in pretty much any programming language and standard libraries. So, it makes sense. However, if you're creating such a format, the least one should do, is write a sibling standard for how to directly binary encode the data. This isn't a hard thing to do. It just need a standard for how to do it, so everyone agrees. Here is an example online on how a rudimentary implementation could be done for OBJ files, but the principle is the same. That way you could chose to export either as 3MF or 3MFB (for binary), and as long as your slicer, and what not, can decode it, you're good.
The hard part of 3MF was all the great work in standardizing what, and how that is represented.