The feature I said no to (and the one I found instead)

One of the more useful things that has happened to Calendula was a feature I turned down, in public, in a comment thread with the person who asked for it (#7).

The request: let Calendula save its calendar state to a file. Prompt for an .ics on startup, write back on every change, so events are never “trapped” in the app. Reasonable on its face. My answer was no, and then we got from there to something I did ship.

Why it was a no

Calendula doesn’t own your data. It’s a client for Android’s system calendar provider, and the syncing is left to whatever CalDAV adapter you’ve already set up: DAVx5, SmoothSync, whatever moves your events today. A “write to an .ics on every change” feature would bring back the thing the app exists to avoid, with Calendula handling sync itself.

Live file sync is also hard in a way more effort doesn’t fix. As soon as two sides can edit the same event (a local change and a synced-in change landing on the same slot), something has to decide which wins. CalDAV has machinery for that. The .ics format doesn’t. It was designed for backups and for handing events from one place to another, and continuous writes weren’t part of the plan. Build the feature and you inherit a merge engine you now have to get right forever. As I put it in the thread: as a developer you want a database to talk to, not to hand-roll storage and eat all the hiccups that come with it.

Why saying no in the open mattered

I could have just closed the issue with “out of scope.” Instead we talked it through, and the request opened up into something more specific than the first sentence. What the reporter wanted was a guarantee that their events could exist as a file that isn’t hostage to one app. Live bidirectional sync was only one way to get there. Their words, as we got there: “just a way to automatically write and read into a file without it ever being trapped in the application.”

That’s a much smaller feature: a periodical auto-export. Set an interval, and at that interval your calendar is written out to an .ics. It only goes one direction, so there’s nothing to merge, and export is what the format was made for. That became #8, and it met the actual need. “That satisfies me!” was how the thread closed.

I also pointed them at ICSx5, which can subscribe to a local .ics file and mirror it into the system calendar. That covers the reading half, one way and read-only. For true two-way file sync I said a separate app, following the DAVx5 pattern, would be the right home. I don’t know of one that exists yet. Their original idea deserves a real solution, just not one bolted into a calendar client.

What I took from the thread

I treat open standards as a boundary. The .ics request sat just outside it, and holding that line kept the app simple enough to trust. What I learned from this one is that a good “no” takes a conversation. The user got something that works, I got a clearer idea of what the app is for, and the thread stays public, so the next person can read the whole reasoning instead of a closed issue with one terse label.