midges can fly, so presumably they would hit the web at random points. as to why flying would be useful for the midges, if they consume biofilms on the surfaces, that's less clear. perhaps over time the midges will evolve away from flying and the spiders will have to adjust their strategy.
This is based on the Dear ImGui library/framework [0]. It's not intended, strictly speaking, for standard desktop applications. It's intended for applications that use 3d rendering, like games or CAD.
Although you could certainly use it as a desktop editor if you wanted to, I think the real value is in embedding.
The practical demonstration in the video are fun and memorable. Realistically I'd take a lighter case without ability to submerge the whole thing in mud and set fire to it, but I'm in urban UK. It seems to be built for a warzone, milled out of solid aluminium?
Or built for a place with only dirt roads, heavy muds during a rainy season, probably very limited ability to get spare parts, and a desire to use it for years after buying it.
I'd have thought reducing weight would provide more utility (in rural monsoon areas, say) if violent contact wasn't part of the problem - it might survive crashes that destroy the bike, maybe that's the design decision.
FWIW, I'm not saying it's wrong, just notable in the apparent robustness.
I don't think 64 RFID antennas would be that bad - you can etch them onto a PCB. That would be a pretty large PCB, I guess, but you could segment it if necessary.
Good point! We use a database (SQLite or Postgres) to enable more advanced features like versioning, collaboration, and access control, which aren't easily managed with static files alone. The database also allows us to scale better for teams with frequent updates.
While it does limit deployment to platforms like GitHub Pages, Kalmia is designed for teams that need more than just static documentation—think of it as a middle ground between static site generators and fully dynamic CMS solutions. For purely static sites, there are other great options out there, but Kalmia focuses on more interactive, collaborative documentation.
That said, we’re actually interested in providing an option for users to export and deploy it to platforms like GitHub Pages or similar, so stay tuned for future updates on that!
You could look into frontmatter to store metadata within the files, and just load it all into memory on startup. Even for huge projects, that probably won’t hurt anyway.
We already load all the documentation assets into memory whenever something changes. Even with large projects spanning hundreds of pages and page groups, it remains very fast—under 1 second in our testing.
That being said, there are some cases where a database is necessary. For example, handling multiple people editing the same document simultaneously wouldn’t work well with just flat files. Also, where would we store user emails/passwords for authentication? Another feature Kalmia supports is private documentation, where users need to log in to access certain docs (there's a simple toggle to enable authentication).
That said, adding an "export to zip" or "push to git" button is totally feasible, and it's something we've had a lot of requests for. While we don't personally use it, we'll be adding it so people can host their docs on static file platforms without needing Kalmia as the backend.
The nice thing about flat files represented in memory would really be maximum performance, no external data store necessary, and easy portability. I definitely understand that sorting out concurrency by using a DBMS is easier, however.
> Also, where would we store user emails/passwords for authentication?
For this kind of application, I’d strongly recommend (and request from anything I buy) OAuth signin via my existing identity provider. That means I don’t have yet another location for accounts, and you don’t have to worry about storing them securely.
Slightly tangential: if you are hacking on PDFs, manually or otherwise, this is an incredibly useful tool: https://pdfcpu.io/ (not the author, just a user)
reply