foxcpp
Calendar Support
Use case
Calendar support for WebDAV, CalDAV and CardDAV.
What problem you are trying to solve?
A monolithic integration of calendar service and mail. The calendar then uses the same credentials of the mail users.
How your solution would work in general?
Use go-webdev package to provide calendar service: https://github.com/emersion/go-webdav
A new thread serves the calendar along with mail service on other threads. Sharing the same credentials and facilitating the usage of both services is the key.
go-webdav needs a lot of work before it can be used as a production-ready CalDAV/CardDAV implementation.
And we probably need a generic HTTP endpoint implementation in maddy first (some discussion in #374). After all that, integration should be as simple as providing an appropriate FS interface implementation built around existing maddy abstractions.
We can start with HTTP reverse-proxy that would run in front of a proper WebDAV implementation and use maddy's authentication modules.
we can start with non prod ready and mark it experimental like some modules in linux kernel,
Sounds like a good candidate for a scope creep. Wouldn't it make sense to use more mature Baikal/EteSync?
@savchenko what about having two separate source of credentials ? Maddy is not (yet) targeting more complex authentication methods like LDAP. So to have a seamless calendar support, it should be part of Maddy. Nowadays calendar is part of the email services.
Even with LDAP support I do not think integrating calendar into maddy is a "scope creep". The reason I use maddy is the fact that it packs up several services into one. It is simple to setup and maintain (so far) and calendar is a so necessary element alongside an email service.
Mail server should be just that - a mail server. Mail has nothing to do with a calendar. While I understand the desire to have a convenient combo, this really is a great candidate for a scope creep.
There's radicale, etesync or https://github.com/emersion/go-webdav - and even they themselves don't even offer any kind of well-rounded documentation to use their package yet (judging by this).
Complicating dev's life with adding something that bloats the business case while not even IMAP storage is marked as production-read would probably not be the wisest choice out there.
