CalDAV support

[zCri]

Added support for CalDAV, fixing issue #207. If anybody could help me test it further before merges it would be great since I don't use proton calendar so I don't have that many calendar events to test it with.

Clients tested:

• GNOME Evolution
• Thunderbird
• KDE KOrganizer (partially)

Functionalities:

• Operate on multiple calendars from the same account
• Read events
• Delete events
• Create / Update events (currently without attendee invitation functionality)
• Notifications

TODOs:

• Caching
• Attendee invitations

[emersion]

Sorry, I don't have time to review this right now. Will try to get to it at some point. Feel free to ping again in a month or so.

[jmomort]

I wasn't able to get this to work on Mac OS or Fantastical. It hits https://github.com/emersion/go-webdav/blob/master/caldav/server.go#L667-L669 I think

[zCri]

I wasn't able to get this to work on Mac OS or Fantastical. It hits https://github.com/emersion/go-webdav/blob/master/caldav/server.go#L667-L669 I think

Hi, I've taken a quick look at Fantastical (on Windows because I have no means to test it on macOS), and although the UI is great it hasn't really been a pleasant experience because it's very buggy, it would refuse to connect to the calendar using localhost, and would not let me remove the calendar after I added it (preventing me from testing some stuff). I don't know exactly if this is the issue you are facing (since it's not related to the link you posted) but I did end up finding a bug in the write support (the read works fine for me), where the client does not increment the SEQUENCE prop on the ical data (and proton requires it to be incremented on change). I can't tell whether it is an issue on my end or if it's a bug in Fantastical (most likely since the other clients i have tested worked fine and incremented SEQUENCE) however I can't really test it because it doesn't let me remove the calendar after I added it (not even by resetting the app in the Windows settings or reinstalling it). If you could tell me exactly how to reproduce the issue you are having I could try looking into it however for this bug I found I'm not sure if its something I have to fix or if we'll have to wait for Fantastical to fix it. I'll look into it later maybe when I have the time.

[zCri]

Sorry, I don't have time to review this right now. Will try to get to it at some point. Feel free to ping again in a month or so.

@emersion hello, sorry to disturb, is there any chance you could take a look at it now?

[jmomort]

I got the issue on Mac OS native Calendar app, too. It fails while setting up the account.

[zCri]

I got the issue on Mac OS native Calendar app, too. It fails while setting up the account.

I tracked the issue down to PROPPATCH not being implemented in https://github.com/emersion/go-webdav/ This code snippet seems to fix it (although of course it's not an actual implementation, it's just a NO-OP to satisfy MacOS).

func (b *backend) PropPatch(r *http.Request, update *internal.PropertyUpdate) (*internal.Response, error) {
    //TODO Actually implement it maybe? Currently NO-OP to fix MacOS Calendar
    resp := internal.NewOKResponse(r.URL.Path)

    for _, prop := range update.Remove {
        if err := resp.EncodeProp(http.StatusOK, prop); err != nil {
            return nil, err
        }
    }
    for _, prop := range update.Set {
        if err := resp.EncodeProp(http.StatusOK, prop); err != nil {
            return nil, err
        }
    }

    return resp, nil
}

Making a pull request in the other repository would require me to first of all wait for the new PR to get merged (and I'm assuming it's not gonna be quick) and then I would also have to adapt this code to use the latest version of go-webdav which introduces some breaking changes which i would need to fix (not only on the CalDAV part which is the only part i worked on and know) and currently I cannot work on that. If the repository owner gets back at me I may take a look at it quicker.

[ajkessel]

Hey @zCri I attempted to reach out to you by email--I've discussed with the developer and my understanding is he is in maintenance mode on this repo and not planning to make substantial investments. He was fine with a proposed fork for more active development. I've tried to reach out to a few other PR-submitters to see if anyone is interested in taking up a "main" active fork.

[zCri]

Hey @zCri I attempted to reach out to you by email--I've discussed with the developer and my understanding is he is in maintenance mode on this repo and not planning to make substantial investments. He was fine with a proposed fork for more active development. I've tried to reach out to a few other PR-submitters to see if anyone is interested in taking up a "main" active fork.

@ajkessel Hey, sorry if I didn't see your email, and yeah I agree that forking this project would be a good idea and would greatly benefit the userbase of this tool, however I'm afraid I'm not the best fit for the task since I'm currently very busy with school, and besides, I don't really use the tool so I cannot have a great feel for what the userbase wants (I took on fixing this issue just because of the bounty on it). I'm happy contributing where needed to at least get this feature merged and working though.

[juxuanu]

Was there any movement regarding this?

[zCri]

Was there any movement regarding this?

Not really i haven't really received any reply

[ajkessel]

I think we need to fork in order to have active development.

[jmomort]

Is https://github.com/acheong08/ferroxide the community work?

[acheong08]

I tried to fix a few things but failed & ran out of time. A dependency bump seemingly broke sending emails to non-protonmail addresses.

Currently archived until I have stable free time.