TODO

• settings file to not have hardcoded credentials
• change production credentials
• nix flake with complete module
• post behavior (simple)
• post behavior (concurrent protection)
• check if better http server availible or fastcgi better suited
• parse args to not hardcode config location
• cleanup nix flake
• de-duplicate hard coded strings in flake

Goals

The goal is to make a service between a m5paper and my radicale (caldav) server. The service will query the caldav server and modify the data in an easy to digest csv that can be sent back and forth without issues.

Problems to solve

Caldav format too hard to parse. Prefer to use a high level library. High level library can't run on esp32. Need a third party.

Justification of choices

The time invested in a proper caldav format parser would take too much time reading a specification, and not enough enjoying/learning programming. An intermediary could prove interesting as I want to use a self-signed cert to authenticate, which I never did (everything goes trough ldap or authelia behind a reverse proxy atm). It also forces me to learn enough about caldav to be interesting yet not cumbersome. (The rfc doc is very long, and does feel like a chore to read). Using python is kinda in line with having a radicale server, and shouldn't add too many additional moving pieces. (Few new libraries, and they are generally stable) Json would be the more portable/self documented choice, but I want to do the parser myself, and a correct json parser is way harder than a csv one. (Especially since it will use c language.) For simplicity the client can only fetch from a hard coded calendar, this choice is justified by needing to specify the certificate anyway manually, so there is no point in doing a config-free interface. Always returning the whole list even on a simple post is deemed good practice to have a restfull api that is simple, and we don't care about power consumption/ressource usage of esp32 during post, as thoses are rare and good practices on idle behavior are deemed more important. Allows a call to fetch the specified caldav (specified in the config, not via a request, as usage) Nix will be used as it is planned to be deployed on nixos like the rest of my web infrastructure (simply the best to not get overwhelmed by the amount of tweaking I do)

client facing interface specification

GET / -> gets 10 next tasks of calendar data as a csv containing an id, a boolean value (0 or 1), and a string (terminated by a \n, no carriage return windows bullshit) POST /id -> checks the item -> returns same as GET /

parent server facing interface specification

GET -> find a way to get the list of VTODO on the specified calendar. POST -> find post the updated item

internal logic

Filter requests by due date and truncate them. Update an item with respecting repeating events parse to csv update list according to csv conflict management policy