1
0
Fork 0
mirror of https://github.com/Kozea/Radicale.git synced 2025-08-01 18:18:31 +00:00

Fix footnotes

This commit is contained in:
Unrud 2020-02-27 14:14:02 +01:00
parent e6c25e3659
commit 452aadcee9

View file

@ -66,10 +66,10 @@ Project and the global architectures of its different parts.
Radicale is written in pure Python and does not depend on any library.
It is known to work on Python 2.6, 2.7, 3.1, 3.2, 3.3, 3.4 and PyPy \>
1.9. The dependencies are optional, as they are only needed for various
authentication methods\[1\].
authentication methods[\[1\]](#footnotes/1).
Linux and MacOS users certainly have Python already installed. For
Windows users, please install Python\[2\] thanks to the adequate
Windows users, please install Python[\[2\]](#footnotes/2) thanks to the adequate
installer.
#### Radicale
@ -1262,11 +1262,6 @@ module](http://docs.python-requests.org/en/latest/).
The daemon mode relies on forks, and thus only works on Unix-like OSes
(incuding Linux, OS X, BSD).
1. See [Python Versions and OS
Support](#documentation/user-documentation/python-versions-and-os-support) for further information.
2. [Python download page](http://python.org/download/).
## Project Description
### Main Goals
@ -1295,34 +1290,19 @@ different authentication methods.
Radicale is a server, not a client. No interfaces will be created to
work with the server, as it is a really (really really) much more
difficult task\[1\].
difficult task[\[3\]](#footnotes/3).
#### Original Calendar or Contact Access Protocol
CalDAV and CardDAV are not perfect protocols. We think that their main
problem is their complexity\[2\], that is why we decided not to
problem is their complexity[\[4\]](#footnotes/4), that is why we decided not to
implement the whole standard but just enough to understand some of its
client-side implementations \[3\].
client-side implementations [\[5\]](#footnotes/5).
CalDAV and CardDAV are the best open standards available and they are
quite widely used by both clients and servers\[4\]. We decided to use
quite widely used by both clients and servers[\[6\]](#footnotes/6). We decided to use
it, and we will not use another one.
1. I repeat: [we are
lazy](#documentation/technical-choices/global-technical-choices/development-choices/lazy).
2. Try to read
[RFC 4791](http://www.faqs.org/rfcs/rfc4791.html "RFC 4791"). Then
try to understand it. Then try to implement it. Then try to read it
again.
3. Radicale is [oriented to calendar user
agents](#documentation/technical-choices/global-technical-choices/development-choices/oriented-to-calendar-and-contact-user-agents).
4. [CalDAV
implementations](http://en.wikipedia.org/wiki/CalDAV#Implementations),
by Wikipedia.
## Technical Choices
### Global Technical Choices
@ -1389,8 +1369,8 @@ covering lots of features and use cases, but it is quite hard to
implement fully.
Some calendar servers have been created to follow the CalDAV and CardDAV
RFCs as much as possible: Davical\[1\], Cosmo\[2\] and Darwin Calendar
Server\[3\], for example, are much more respectful of CalDAV and CardDAV
RFCs as much as possible: Davical[\[7\]](#footnotes/7), Cosmo[\[8\]](#footnotes/8) and Darwin Calendar
Server[\[9\]](#footnotes/9), for example, are much more respectful of CalDAV and CardDAV
and can be used with a large number of clients. They are very good
choices if you want to develop and test new CalDAV clients, or if you
have a possibly heterogeneous list of user agents.
@ -1419,7 +1399,7 @@ Documentation](#documentation/user-documentation).
##### Lazy
We, Radicale Project developers, are lazy. That is why we have chosen
Python: no more `;` or `{}`\[4\]. This is also why our server is lazy.
Python: no more `;` or `{}`[\[10\]](#footnotes/10). This is also why our server is lazy.
The CalDAV RFC defines what must be done, what can be done and what
cannot be done. Many violations of the protocol are totally defined and
@ -1538,19 +1518,6 @@ The package offers 8 modules.
<!-- end list -->
1. [Davical](http://www.davical.org/), a standards-compliant calendar
server.
2. [Cosmo](http://chandlerproject.org/Projects/CosmoHome), the web
contents and calendars sharing server build to support the Chandler
Project.
3. [Darwin Calendar Server](http://trac.calendarserver.org/), a
standards-compliant calendar server mainly developed by Apple.
4. Who says "Ruby is even less verbose\!" should read the
[PEP 20](http://www.python.org/dev/peps/pep-0020/ "PEP 20").
# Contribute
### Chat with Us on IRC
@ -2519,3 +2486,58 @@ view and download source code.
The Radicale Project is launched. The code has been cleaned up and will
be available soon…
# Footnotes
### 1
See [Python Versions and OS
Support](#documentation/user-documentation/python-versions-and-os-support) for further information.
### 2
[Python download page](http://python.org/download/).
### 3
I repeat: [we are
lazy](#documentation/technical-choices/global-technical-choices/development-choices/lazy).
### 4
Try to read
[RFC 4791](http://www.faqs.org/rfcs/rfc4791.html "RFC 4791"). Then
try to understand it. Then try to implement it. Then try to read it
again.
### 5
Radicale is [oriented to calendar user
agents](#documentation/technical-choices/global-technical-choices/development-choices/oriented-to-calendar-and-contact-user-agents).
### 6
[CalDAV
implementations](http://en.wikipedia.org/wiki/CalDAV#Implementations),
by Wikipedia.
### 7
[Davical](http://www.davical.org/), a standards-compliant calendar
server.
### 8
[Cosmo](http://chandlerproject.org/Projects/CosmoHome), the web
contents and calendars sharing server build to support the Chandler
Project.
### 9
[Darwin Calendar Server](http://trac.calendarserver.org/), a
standards-compliant calendar server mainly developed by Apple.
### 10
Who says "Ruby is even less verbose\!" should read the
[PEP 20](http://www.python.org/dev/peps/pep-0020/ "PEP 20").