kitchen-fridge is a CalDAV (iCal file transfer over WebDAV) Rust client library.
CalDAV is described as "Calendaring Extensions to WebDAV" in [RFC 4791](https://datatracker.ietf.org/doc/html/rfc4791) and [RFC 7986](https://datatracker.ietf.org/doc/html/rfc7986) and the underlying iCal format is described at least in [RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545). \
This library has been intensivley tested with Nextcloud servers. It should support Owncloud and iCloud as well, since they use the very same CalDAV protocol.
Its [documentation](https://docs.rs/kitchen-fridge/) is available on docs.rs.
Its [documentation](https://docs.rs/kitchen-fridge/) is available on docs.rs.
CalDAV is described as "Calendaring Extensions to WebDAV" in [RFC 4791](https://datatracker.ietf.org/doc/html/rfc4791) and [RFC 7986](https://datatracker.ietf.org/doc/html/rfc7986) and the underlying iCal format is described at least in [RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545).
/// It automatically updates the content of the folder when dropped (see its `Drop` implementation), but you can also manually call [`Cache::save_to_folder`]
/// It automatically updates the content of the folder when dropped (see its `Drop` implementation), but you can also manually call [`Cache::save_to_folder`]
///
///
/// Most of its methods are part of the `CalDavSource` trait implementation
/// Most of its functionality is provided by the `CalDavSource` async trait it implements.
/// However, since these functions do not _need_ to be actually async, non-async versions of them are also provided for better convenience. See [`Cache::get_calendar_sync`] for example
@ -19,18 +19,19 @@ use crate::mock_behaviour::MockBehaviour;
/// A calendar used by the [`cache`](crate::cache) module
/// A calendar used by the [`cache`](crate::cache) module
///
///
/// Most of its methods are part of traits implementations
/// Most of its functionality is provided by the async traits it implements.
/// However, since these functions do not _need_ to be actually async, non-async versions of them are also provided for better convenience. See [`CachedCalendar::add_item_sync`] for example
//! This crate provides a way to manage CalDAV data.
//! This crate provides a CalDAV client library. \
//! CalDAV is described as "Calendaring Extensions to WebDAV" in [RFC 4791](https://datatracker.ietf.org/doc/html/rfc4791) and [RFC 7986](https://datatracker.ietf.org/doc/html/rfc7986) and the underlying iCal format is described at least in [RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545). \
//! This library has been intensivley tested with Nextcloud servers. It should support Owncloud and iCloud as well, since they use the very same CalDAV protocol.
//!
//!
//! Its initial implementation only supported TODO events, so that it could fetch and update a CalDAV-hosted todo-list...just like [sticky notes on a kitchen fridge](https://www.google.com/search?q=kitchen+fridge+todo+list&tbm=isch) would. \
//! This initial implementation only supports TODO events. Thus it can fetch and update a CalDAV-hosted todo-list...just like [sticky notes on a kitchen fridge](https://www.google.com/search?q=kitchen+fridge+todo+list&tbm=isch) would. \
//! Supporting other items (and especially regular CalDAV calendar events) should be fairly trivial, as it should boil down to adding little logic in iCal files parsing, but any help is appreciated :-)
//! Supporting other items (and especially regular CalDAV calendar events) should be fairly trivial, as it should boil down to adding little logic in iCal files parsing, but any help is appreciated :-)
//!
//!
//! ## Possible uses
//! ## Possible uses
@ -12,14 +14,20 @@
//!
//!
//! These two "data sources" (actual client and local cache) can be used together in a [`CalDavProvider`](CalDavProvider). \
//! These two "data sources" (actual client and local cache) can be used together in a [`CalDavProvider`](CalDavProvider). \
//! A `CalDavProvider` abstracts these two sources by merging them together into one virtual source. \
//! A `CalDavProvider` abstracts these two sources by merging them together into one virtual source. \
//! It also handles synchronisation between the local cache and the server.
//! It also handles synchronisation between the local cache and the server, and robustly recovers from any network error (so that it never corrupts the local or remote source).
//!
//!
//! Note that many methods are defined in common traits (see [`crate::traits`]).
//! Note that many methods are defined in common traits (see [`crate::traits`]).
//!
//!
//! ## Examples
//! ## Examples
//!
//!
//! See example usage in the `examples/` folder, that you can run using `cargo run --example <example-name>`. \
//! See example usage in the `examples/` folder, that you can run using `cargo run --example <example-name>`. \
//! You can also have a look at `tasklist`, a GUI app that uses `kitchen-fridge` under the hood.
//! You can also have a look at [`Voilà`](https://github.com/daladim/voila-tasks), a GUI app that uses `kitchen-fridge` under the hood.
//!
//! ## Configuration options
//!
//! Have a look at the [`config`] module to see what default options can be overridden.
/// A data source that combines two `CalDavSource`s, which is able to sync both sources.
/// A data source that combines two `CalDavSource`s, which is able to sync both sources.
///
///
/// Usually, you will only need to use a provider between a server and a local cache, that is to say a [`CalDavProvider`](crate::CalDavProvider), i.e. a `Provider<Cache, CachedCalendar, Client, RemoteCalendar>`. \
/// Usually, you will only need to use a provider between a server and a local cache, that is to say a [`CalDavProvider`](crate::CalDavProvider), i.e. a `Provider<Cache, CachedCalendar, Client, RemoteCalendar>`. \
progress.debug(&format!("> Applying a batch of {} locally",batch_type)/* too bad Chunks does not implement ExactSizeIterator, that could provide useful debug info. See https://github.com/rust-itertools/itertools/issues/171 */);
@ -4,10 +4,10 @@ use serde::{Deserialize, Serialize};
useuuid::Uuid;
useuuid::Uuid;
usechrono::{DateTime,Utc};
usechrono::{DateTime,Utc};
useical::property::Property;
useical::property::Property;
useurl::Url;
usecrate::item::ItemId;
usecrate::item::SyncStatus;
usecrate::item::SyncStatus;
usecrate::calendar::CalendarId;
usecrate::utils::random_url;
/// RFC5545 defines the completion as several optional fields, yet some combinations make no sense.
/// RFC5545 defines the completion as several optional fields, yet some combinations make no sense.
/// This enum provides an API that forbids such impossible combinations.
/// This enum provides an API that forbids such impossible combinations.
@ -33,10 +33,11 @@ impl CompletionStatus {
#[derive(Clone, Debug, Serialize, Deserialize)]
#[derive(Clone, Debug, Serialize, Deserialize)]
pubstructTask{
pubstructTask{
/// The task URL
/// The task URL
id: ItemId,
url: Url,
/// Persistent, globally unique identifier for the calendar component
/// Persistent, globally unique identifier for the calendar component
/// The [RFC](https://tools.ietf.org/html/rfc5545#page-117) recommends concatenating a timestamp with the server's domain name, but UUID are even better
/// The [RFC](https://tools.ietf.org/html/rfc5545#page-117) recommends concatenating a timestamp with the server's domain name.
/// UUID are even better so we'll generate them, but we have to support tasks from the server, that may have any arbitrary strings here.
uid: String,
uid: String,
/// The sync status of this item
/// The sync status of this item
@ -65,8 +66,8 @@ pub struct Task {
implTask{
implTask{
/// Create a brand new Task that is not on a server yet.
/// Create a brand new Task that is not on a server yet.