Using a calendar as backend/for data storage for synchronisation purposes.

[RobertZenz]

Currently the data we gather is stored in a SQLite database. Synchronising this data over multiple devices (Phone, Tablet, PC) requires some, uh, "home made" solutions. Given that the data is always in the form of "Date and Time, Something", it might be possible to actually use a calendar to store this data. Calendars have either first-class support for synchronization (Google, maybe others) or have very good third-party solutions (ICSx5, DAVx5). This would not only allow to synchronize the data over multiple devices, but would also allow third-party applications to easily access it (for example a NextCloud app) and make use of it.

Feasibility is an complete unknown to me, to be honest, so I'll type out my thoughts about it:

1. I'm not doing Kotlin (or Android development, for that matter) so I have a hard time seeing how much work it would be to have a different backend at all.
2. There is the "problem" that calendars are most of the time not loaded completely from the server, but rather a certain timespan (for example the last three months) is being loaded (DAVx5 for example has this configurable).
   1. Given that, the question arises from where to load the structure of the database from. Tracking it in every entry is out of the question, and the thought to have a "description" entry at something like "1970-01-01" might not be working either because the whole calendar might not be loaded.
   2. Changes to the structure of the tracked data can most likely not be propagated throughout the whole dataset (not loaded), which would require a certain "permissiveness" when it comes to the data being read from the calendar. This might even require a versioning of the changes to be able to apply these transformations on the fly when reading data.
   3. Displaying all data is also limited to the set loaded, but I guess that is one of the smaller problems.
   4. Migrating between backends would only be feasible in one direction: SQLite to CalDav. The other way around can only be seen as "import all the available data".
3. In what format to store the data inside the calendar entry is another question, but XML or JSON are the obvious options readily available. Both options are also easily processable by third-party applications.

So, reading that again, that might not be feasible at all.

[stheid]

i think it makes more sense to look at how "keepass for android" handles this. They allow sync of the databases over multiple services.

I think saving the data as a calendar is even hackier.

[SamAmco]

Agreed, I think you have answered your own question there. If you require a cloud solution then there are probably better ones out there to integrate with. I will close this issue.