对于CalDAV，如何避免时间冲突或重叠？ [英] How to avoid time conflict or overlap for CalDAV?

问题描述

我正在研究CalDAV协议。

我对CalDAV的时间冲突或重叠存在一些疑问。

让我举例说明一些情况。
我在日历中做了一个PM1〜PM6事件。然后，我尝试在同一日历中进行另一个事件PM2〜7。是时间冲突或重叠。

CalDav服务器如何解决此冲突？服务器在第二个事件发生时是否出错？

我确实搜索了RFC6638。但是我找不到解决方案。
请解决我的问题。

感谢阅读。

解决方案

Kim要求为商务日历系统提供一种非常通用的功能（没有同一个人预订两次等）。

我认为在CalDAV世界中这有两个部分：

a）首先，客户端应该执行忙查询以检查
用户是否可用。然后显示冲突警告或
（如果合适）。

这是包括btw Exchange在内的系统数量。 Siri也会进行这种冲突检测（嘿，您当时已经有一个事件，我是否仍要创建一个冲突事件，主人？）

b）但是在一个合理的系统中，您实际上需要保证
的信息在PUT时不会过时。即

我认为在CalDAV中，您可以通过测试 sync-来实现这一目标。令牌或 CTag ，使用 PUT上的 If 标头。即让 PUT 仅在整个基础集合不变的情况下成功。如果这样做（ PUT 会因冲突而失败），请重做忙碌状态，然后重试。

我认为CalDAV交叉收藏夹（日历）中没有可靠的方法来执行此操作，也就是说，如果资源的可用性由于在其他日历中预订而发生了变化，则目标同步收藏夹通常不会更改它的同步代码和 PUT 将会一直运行。
CalDAV（带调度）的坏处是PUT不再是幂等的。否则，您可以执行 PUT ，重新检查它是否仍然没有冲突，如果有的话，将其删除。

I am studying CalDAV protocol.

I have some question for time conflict or overlap for CalDAV.

Let me explain by instance for some scenario. I made an event PM1 ~ PM6 in calendar. And then I try to made another event PM2~7 in same calendar. It is time conflict or overlap.

How does CalDav server resolve this conflict? Does server make error when second event make?

I did search out RFC 6638. But I could not find solution. Please help my question.

Thanks for reading.

解决方案

The functionality Kim is asking for a very common one for business calendaring systems (not have the same person booked twice etc).

I think in the CalDAV world there are two parts to this:

a) First the client is supposed to perform a freebusy query to check whether a user is available. And then show a conflict warning or whatever seems appropriate.

This is how many systems, including btw Exchange work. Siri also does this kind of conflict detection ("hey, you already have an event at the time, shall I still create the conflicting one, master?")

b) But in a reasonable system you actually need to guarantee that the information isn’t outdated at PUT time. I.e. that no second client has scheduled the same attendee/resource.

I think in CalDAV you can accomplish that by testing the sync-token or the CTag using an If header on the PUT. I.e. let the PUT only succeed if the whole underlying collection didn’t change. And if it did (the PUT will fail with a conflict), redo the freebusy, then try again.

I don’t think that there is a reliable way to do this in CalDAV cross collections (calendars), that is, if the availability of a resource changed because it got booked in a different calendar, the targeted sync collection won’t usually change its sync tag and the PUT would run through. The bad thing about CalDAV (w/ scheduling) is that PUTs are not idempotent anymore. Otherwise you could do the PUT, recheck whether it still has no conflicts, and if so drop it after the fact.

这篇关于对于CalDAV，如何避免时间冲突或重叠？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！