Closed f1-outsourcing closed 3 years ago
Hi @f1-outsourcing ,
You can start by having a look at the demo application.
The demo application uses an embedded MariaDB instance. For a production environment you should configure a real MariaDB instance allocating as much hardware as you need. You can do that using spring profiles and yaml configuration files.
The demo application has a 'dummy' authentication provider that allows any user to connect to the application. Obviously you need to change that and provide your own Authentication Provider implementation. You can build one relying on the cosmo tables, or you can delegate the authentication calls to a third party system.
If you want to perform any additional actions when an event is added to a customer's calendar you can use your own EventAddHandler
implementations and they will be picked up automatically by the framework.
Cosmo is a stateless application so you can deploy as many instances as you want and then configure a Load Balancer in front of them by using whatever software you like (apache, nginx etc.)
Being a SpringBoot application, any bean declaration can be overwritten by using the @Primary
annotation, giving you the flexibility you need.
Cheers,
The demo application uses an embedded MariaDB instance. For a production environment you should configure a real MariaDB instance allocating as much hardware as you need. You can do that using spring profiles and yaml configuration files.
Yes indeed very nice quick way to test.
The demo application has a 'dummy' authentication provider that allows any user to connect to the application. Obviously you need to change that and provide your own Authentication Provider implementation. You can build one relying on the cosmo tables, or you can delegate the authentication calls to a third party system.
I would be doing this to users in openldap.
If you want to perform any additional actions when an event is added to a customer's calendar you can use your own
EventAddHandler
implementations and they will be picked up automatically by the framework.
Interesting, what would be a practical application?
Cosmo is a stateless application so you can deploy as many instances as you want and then configure a Load Balancer in front of them by using whatever software you like (apache, nginx etc.)
Very nice, is there maybe a Dockerfile example available? :)
How do the instances of cosmo-caldav-server compare to the required mariadb instances?
Is there any caching being done at the caldav-server, and that data is lost when the instance is terminated?
And if you scale the caldav-server instance, how are queries spread among (master-master?) instances of mariadb?
Interesting, what would be a practical application?
For instance you could use an EventAddHandler
implementation to send invitation emails to the list of attendees when an event has ones.
Very nice, is there maybe a Dockerfile example available? :)
There isn't a Docker image. I explained the reasons in this ticket https://github.com/1and1/cosmo/issues/39
How do the instances of cosmo-caldav-server compare to the required mariadb instances? Is there any caching being done at the caldav-server, and that data is lost when the instance is terminated? And if you scale the caldav-server instance, how are queries spread among (master-master?) instances of mariadb?
All the caching and data base stuff can be configured by providing the appropriate properties for Hibernate
and for the HikariDataSource
. You are only limited by the constraints of these two frameworks. You can even switch to another database connection pooling implementation if you like (a while ago the sample application used TomcatJDBC)
Cheers,
Hi Daniel,
Is this project mostly designed to facilitate Chandler or does this also intend to support other caldav clients? Sometimes you see on caldav repositories that they list RFC numbers, maybe nice to add also?
Hi @f1-outsourcing
As far as I know Chandler project was abandoned a while ago, 1&1 maintained only the cosmo project form the original suite. Cosmo is a CalDAV server that aligns to rfc4791 and in general supports all the CalDAV clients. (We should take into consideration updating the documentation, thanks for your suggestion)
Cheers,
I exchanged some emails with Protonmail (they are about to implement calendar functionality) so I asked a bit what they were using or if they are coding something from scratch. But it seems they are still looking for something to use. So I advised them to have look at yours as well, maybe they are welcome/professional contributors in adding end 2 end encryption.
I do not really understand how one can/should use this implementation of caldav. I have been testing a bit in the past with the calendar and carddav server of apple, but like many other implementations you can find, these are discontinued or not often updated.
(I am also a bit hesitant of using php implementations for something like this) When I saw that 1and1 is using this, and probably on a large scale clustered, it needs to be of some 'professional level'.
Say you have 10.000 users with an android/ios phone doing caldav syncing. How would I setup this server of yours in production?