robur/homepage-data
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

link to live demo

Browse source
This commit is contained in:
Hannes Mehnert 2019-11-19 23:27:11 +01:00
parent 9e89cacdbb
commit 160523ea05
1 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
Our Work/Projects
View file

@ -42,9 +42,11 @@ The CalDAV server project began in 2017 when [Stefanie Schirmer and Hannes Mehne
Currently all basic features of a calendar are implemented, for example "please add this event to the calendar", and "modify the weekly meeting from now on to start half an hour later", and it is tested with a variety of CalDAV clients. Currently all basic features of a calendar are implemented, for example "please add this event to the calendar", and "modify the weekly meeting from now on to start half an hour later", and it is tested with a variety of CalDAV clients.
[calendar.robur.coop](https://calendar.robur.coop) is a live test server with the [calDavZAP](https://www.inf-it.com/open-source/clients/caldavzap/) web user interface, try it with any user and any password (first come first serve), it persists to a remote git repository.
Our CalDAV server has a very small codebase which provides a number of security benefits and it stores all the data in git so there is a history of changes, it can easily be exported and converted to and from other formats, and if a client behaves badly (by removing entries they cannot deal with), this can be tracked and reverted. Our CalDAV server has a very small codebase which provides a number of security benefits and it stores all the data in git so there is a history of changes, it can easily be exported and converted to and from other formats, and if a client behaves badly (by removing entries they cannot deal with), this can be tracked and reverted.
We would like to develop the CalDAV server further, adding notifications about updates and invitations sent via Mail (as described in [RFC 6638](https://tools.ietf.org/html/rfc6638)). In addition, currently it is a server only, and we would like to integrate a pure JavaScript client as a user interface in the same unikernel [such as CalDavZAP](https://www.inf-it.com/open-source/clients/caldavzap/). We also aim to integrate the related protocol CardDAV (address book), which could be integrated into the same unikernel. We would like to develop the CalDAV server further, adding notifications about updates and invitations sent via Mail (as described in [RFC 6638](https://tools.ietf.org/html/rfc6638)). We also aim to integrate the related protocol CardDAV (address book), which could be integrated into the same unikernel.
If you are interested in supporting further work on the CalDAV server through a [donation](/Donate), with a grant, or require additional features to be implemented to accommodate your project’s needs please [get in touch with us](/Contact)! If you are interested in supporting further work on the CalDAV server through a [donation](/Donate), with a grant, or require additional features to be implemented to accommodate your project’s needs please [get in touch with us](/Contact)!
@ -63,7 +65,7 @@ The CalDAV server is open source, with the code available on GitHub for the [ser
# DNS # DNS
The Domain Name System is used like a phone book for the internet - it translates human-memoizable domain names (e.g. robur.io) to machine-routable IP addresses (e.g. 198.167.222.215) and other records such as where eMail should be sent to. DNS is a fault-tolerant hierarchical decentralized key-value store with caching. DNS has been deployed on the Internet since 1987. The Domain Name System is used like a phone book for the internet - it translates human-memoizable domain names (e.g. robur.coop) to machine-routable IP addresses (e.g. 198.167.222.215) and other records such as where eMail should be sent to. DNS is a fault-tolerant hierarchical decentralized key-value store with caching. DNS has been deployed on the Internet since 1987.
On the one side, the authoritative server, which has delegated responsibility for a domain, provides that mapping information (i.e. that a certain IP is the right one for a certain domain), and on the other side a resolver provides the functionality to figure out which server to request for each query a client has. On the one side, the authoritative server, which has delegated responsibility for a domain, provides that mapping information (i.e. that a certain IP is the right one for a certain domain), and on the other side a resolver provides the functionality to figure out which server to request for each query a client has.