You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: caldav/compatibility_hints.py
+46-15Lines changed: 46 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,9 @@
4
4
encountered while working on the caldav library, and descriptions on
5
5
how the well-known servers behave.
6
6
"""
7
+
8
+
importcopy
9
+
7
10
## NEW STYLE
8
11
## (we're gradually moving stuff from the good old
9
12
## "incompatibility_description" below over to
@@ -18,14 +21,20 @@ class FeatureSet:
18
21
An object of this class describes the feature set of a server.
19
22
20
23
TODO: use enums?
21
-
type -> "client-feature", "server-peculiarity", "server-feature" (last is default)
24
+
type -> "client-feature", "server-peculiarity", "tests-behaviour", "server-observation", "server-feature" (last is default)
22
25
support -> "supported" (default), "unsupported", "fragile", "broken", "ungraceful"
26
+
27
+
types:
28
+
* client-feature means the client is supposed to do special things (like, rate-limiting). While the need for rate-limiting may be set by the server, it may not be possible to reliably establish it by probling the server, and the value may differ for different clients.
29
+
* server-peculiarity - weird behaviour detected at the server side, behaviour that is too odd to be described as "missing support for a feature". Example: there is some cache working, causing a delay from some object is sent to the server and until it can be retrieved. The difference between an "unsupported server-feature" and a "server-peculiarity" may be a bit floating - like, arguably "instant updates" may be considered a feature.
23
30
"""
24
31
FEATURES= {
25
32
"get-current-user-principal": {
26
33
"description": "Support for RFC5397, current principal extension. Most CalDAV servers have this, but it is an extension to the standard",
27
34
"features": {
28
-
"has-calendar": "Principal has one or more calendars. Some servers and providers comes with a pre-defined calendar for each user, for other servers a calendar has to be explicitly created (supported means there exists a calendar - it may be because the calendar was already provisioned together with the principal, or it may be because a calendar was created manually, the checks can't see the difference)"
35
+
"has-calendar": {
36
+
"type": "server-observation",
37
+
"description": "Principal has one or more calendars. Some servers and providers comes with a pre-defined calendar for each user, for other servers a calendar has to be explicitly created (supported means there exists a calendar - it may be because the calendar was already provisioned together with the principal, or it may be because a calendar was created manually, the checks can't see the difference)"}
29
38
}
30
39
},
31
40
"rate-limit": {
@@ -50,6 +59,7 @@ class FeatureSet:
50
59
"description": "RFC4791 says that \"support for MKCALENDAR on the server is only RECOMMENDED and not REQUIRED because some calendar stores only support one calendar per user (or principal), and those are typically pre-created for each account\". Hence a conformant server may opt to not support creating calendars, this is often seen for cloud services (some services allows extra calendars to be made, but not through the CalDAV protocol). (RFC4791 also says that the server MAY support MKCOL in section 8.5.2. I do read it as MKCOL may be used for creating calendars - which is weird, since section 8.5.2 is titled \"external attachments\". We should consider testing this as well)",
51
60
"features": {
52
61
"auto": {
62
+
"default": { "support": "unsupported" },
53
63
"description": "Accessing a calendar which does not exist automatically creates it",
0 commit comments