Collection Storage - Kozea/Radicale GitHub Wiki
-
[d]: directory -
[f]: file
[d] /var
└─[d] /lib
└─[d] /radicale
└─[d] /collections
└─[d] /collection-root
├─[d] /USER1
│ ├─[d] /mycalendar1 (Collection)
│ │ ├─[d] /.Radicale.cache (automatic generated)
│ │ ├─[f] .Radicale.props (set: VEVENT)
│ │ ├─[f] schedule1.ics
│ │ ├...
│ │ └─[f] scheduleX.ics
│ ├─[d] /myaddressbook1 (Collection)
│ ├─[d] /.Radicale.cache (automatic generated)
│ ├─[f] .Radicale.props (set: VJOURNAL)
│ ├─[f] contact1.vcf
│ ├...
│ └─[f] contactX.vcf
│
├─[d] /USER2
¦
Collection on storage is always a directory containing
| Collection Type | Files |
|---|---|
| VCALENDAR | *.ics |
| VADDRESSBOOK | *.vcf |
Property file of collection
Example using jq for pretty-print
jq . .Radicale.props
{
"C:calendar-description": "Schedules",
"C:supported-calendar-component-set": "VEVENT,VJOURNAL,VTODO",
"D:displayname": "Schedules",
"ICAL:calendar-color": "#ffc000ff",
"tag": "VCALENDAR"
}
jq . .Radicale.props
{
"CR:addressbook-description": "AddressBook",
"D:displayname": "AddressBook",
"{http://inf-it.com/ns/ab/}addressbook-color": "#758857ff",
"tag": "VADDRESSBOOK",
}
[d] /var
└─[d] /lib
└─[d] /radicale
└─[d] /collections
└─[d] /collection-root
├─[d] /USER1
¦ ├─[d] /mycalendar1 (Collection)
¦ ├─[d] /.Radicale.cache (automatic generated)
¦ ├─[d] /item (automatic generated)
├─[d] /history (automatic generated)
└─[d] /sync-token (automatic generated)
1:1 reflecting items in a pre-compiled format
Since 3.3.2 the item cache can be located outside by option [storage] use_cache_subfolder_for_item = True in combination with defined filesystem_cache_folder.
Since 3.3.2 the item cache format can be toggled between SHA-256 or using mtime+size of original item by option [storage] use_mtime_and_size_for_item_cache = True (recommend to use only on systems where mtime has "ns" granularity)
historic pre-compiled items
Since 3.3.2 the history can be located outside by option [storage] use_cache_subfolder_for_history = True in combination with defined filesystem_cache_folder.
file containing synchronization tokens related to each client serve only changes on request
Since 3.3.2 the sync-token can be located outside by option [storage] use_cache_subfolder_for_synctoken = True in combination with defined filesystem_cache_folder.
Since 3.3.2 there is the option to store the cache outside the filesystem_folder e.g. [storage] filesystem_cache_folder = /var/cache/radicale/collections/collection-cache
This can be used storing item cache local on the system while the items, sync-token and history are stored in shared filesystem like NFS or GlusterFS.
| Item Storage | Item Cache | History | Sync-Token |
|---|---|---|---|
| Local | possible | possible | possible |
| Remote, single instance | optional(1) | optional(1) | optional(1) |
| Semi-Local or shared, cluster | possible(1) | avoid(2) | avoid(2) |
(1) can decrease response time
(2) will break consistency
Example:
[d] /var
└─[d] /lib
└─[d] /radicale
└─[d] /collections
├─[d] /collection-cache
| ├─[d] /USER1 (1:1 related to below)
| ¦ ├─[d] /mycalendar1 (1:1 related to below)
| ¦ ├─[d] /.Radicale.cache (automatic generated)
| ¦ └─[d] /item (automatic generated)
|
└─[d] /collection-root
├─[d] /USER1
¦ ├─[d] /mycalendar1 (Collection)
¦ ├─[d] /.Radicale.cache (automatic generated)
¦ ├─[d] /history (automatic generated)
└─[d] /sync-token (automatic generated)
Content may be moved, otherwise it's automatic re-generated on next request by client (one-time response delay depending on amount of items)
Content may be moved (in case of interest), otherwise historic data is lost
Content may be moved, otherwise lost and client will on next connection pull more data than usual if sync-token is used on client side