为网站成员发布CalDav事件并管理参与者

Question

我正在运行带有用户数据库和共享日历（事件）审核数据库的PHP站点。

我想在iCal / CalDAV中发布这些事件，以便成员可以：

• 使用身份验证（私人网址...）
获取所有同步的日历活动
• 加入活动
• （但不能创建或修改活动）

该应用应利用网站现有用户和日历数据库。

我已经看过PHP中的CalDav实现了。 Python，对于这种简单的用法来说，它们看起来都太复杂了：

• sabre/dav拥有实验性的共享日历支持，并且利用现有的用户数据库似乎很棘手。
• DAViCal似乎有自己的用户数据库，复杂的ACL方案等。
• 等

怎么做？

• 使用适合的CalDAV / iCal库吗？想知道图书馆会做什么工作吗？
• 编写我自己的CalDAV / iCal服务器，存在客户端支持不佳的风险。

编辑：将saber / dav与现有网站数据库一起使用的有用链接：

• Using external databases

编辑：改进：

• 虽然按预期工作，但是在创建服务器端事件时，saber / DAV的方式太慢，邀请~100名当地人（＆＃ 34;主体＆＃34）。它为每个被邀请者生成99x无用的事件副本。处理邀请花了8秒钟（使用xdebug分析时超过30秒，它就崩溃了！）。

• 关于使用共享日历，标准中只有两种可能性：要么为被邀请者提供读写访问权限，所以他可以加入活动（但也要更改） /删除它！）或给他只读访问权限......但他无法加入。因此，我使用Sabre\CalDAV\Backend\PDO::updateCalendarObject()来限制对参与者PARTSTAT的事件编辑。

但无论解决方案如何，冲突存在问题：

• 当参与者A修改日历条目并表示其参与（PARTSTAT ACCEPTED）时，Sabre / DAV会通过更新所有用户日历中的所有日历对象来处理此信息。执行此操作时，SabreDAV会递增所有这些日历的SYNC标记。

• 因此，当参与者B尝试加入某个活动但未同步参与者A同时加入该活动的信息时，会发生冲突并且参与者B加入信息 LOST

冲突解决方案：

• RFC 6638定义了一种使用schedule-tag来避免此类冲突的方法。这仅适用于v3.3的Sabre / DAV路线图。我已经为saber / dav here 开发了实验性支持但是，我测试过的所有Android客户端都不支持这个RFC，只有iOS支持！无论如何，即使使用schedule-tag，如果组织者更改事件数据或使用共享日历，某些参与者加入信息也将丢失。

• 所以我已经制作了自己的saber / dav实现，大部分都没有丢失参与者加入信息（除非事件是重新安排的）：sabre/dav partstat-only-calendar。基本上，它通过考虑用户发送的冲突EVENT并且仅记录服务器事件中的参与者PARSTAT信息而不是正常推送PreconditionFailed异常来工作。我仍然需要发布一个利用所有功能的服务器运行脚本的例子。

Answer 1

(The question seems a little broad for StackOverflow.)

SabreDAV seems to be the choice when implementing a Cal/CardDAV server in PHP. It very likely makes sense to use it.

a) Get all calendar events, in sync, with authentication (private URL...)

Well, that should be covered.

b) Join an event

I assume your use case is that you have an event, but the user is not proactively invited to it. But you still want the user user to 'add' himself to the event. This is not a use case the CalDAV standard currently supports. There are shared calendars in CalDAV and there are server side scheduled events. I think the latter might work for you.

You could synthesize this 'add-me' behavior. Dynamically add the user as a participant to the event when presenting it to a client. He can then Accept/Maybe/Deny it. If he does, persist that fact in the master event - he is now a regular invitee.

c) (But not create or modify an event)

This is the default behavior for iTIP/CalDAV server scheduled events. Only the ORGANIZER can modify events except for stuff like alarms etc. So that seems to fit your use case.