~whynothugo 1 year, 7 months ago

Both the original [python] vdirsyncer and this new implementation work synchronising items between two storages.

This new version has a Storage trait, of which there are a few implementations: CalDav, Filesystem, etc. All of this is contained in the vstorage crate. As a starting point, I suggest running cargo doc --open and having a look at the existing documentation or these types, plus a few key concepts described in the docs for the crate itself.

A new EteSyncStorage would 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 Storage trait is more or less stable. There are only two pending breaking change in sight:

• 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<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 monitor method will be implemented to monitor a storage for changes. For FilesystemStorage this means using inotify or 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.

~whynothugo 1 year, 7 months ago

Regarding the documentation for the Storage type, see this hint: https://git.sr.ht/~whynothugo/vdirsyncer-rs/commit/2050e21f30e8a720288cb118bbca825dc260ee35

~whynothugo 1 year, 7 months ago

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.

~whynothugo added 3: vstorage 8 months ago

~whynothugo added 4: patches-welcome 8 months ago