I'd like to sync to my etebase accounts. I am willing to contribute. Does it make sense to wait for the library to mature before starting?
Both the original [python] vdirsyncer and this new implementation work synchronising items between two storages.
This new version has a
Storagetrait, of which there are a few implementations:
Filesystem, etc. All of this is contained in the
vstoragecrate. As a starting point, I suggest running
cargo doc --openand having a look at the existing documentation or these types, plus a few key concepts described in the docs for the crate itself.
EteSyncStoragewould need to be implemented. Again, this will be a lot clearer by looking at those docs, but feel free to follow up with any questions here -- the docs have not had another pair of eyes on them so far.
At this moment, the
Storagetrait is more or less stable. There are only two pending breaking change in sight:
The first one will be rather soon. Currently
Storageassumes that all items are of type icalendar. This needs to be made generic (to support anything non-icalendar). This means renaming
IcsItem, and, for example, in the case of the CalDav storage, this means changing
impl Storage for CalDavStorageinto
impl Storage<IcsItem> for CalDavStorage. The type of the item is only relevant for how the UID is extracted.
The second change will be further down the line. A new
monitormethod will be implemented to monitor a storage for changes. For
FilesystemStoragethis means using
inotifyor an equivalent functionality. For some storages, this might mean polling or simply be not-implemented. I don't think you need to worry about this one at all.
Thanks for your interest here, and again: let me know if you have any follow-up questions.
Regarding the documentation for the
Storagetype, see this hint: https://git.sr.ht/~whynothugo/vdirsyncer-rs/commit/2050e21f30e8a720288cb118bbca825dc260ee35
The first one will be rather soon. Currently Storage assumes that all items are of type icalendar. This needs to be made generic (to support anything non-icalendar). This means renaming Item into IcsItem, and, for example, in the case of the CalDav storage, this means changing impl Storage for CalDavStorage into impl Storage for CalDavStorage. The type of the item is only relevant for how the UID is extracted.
This is now done; storages are generic over their item types.