iCal 源的隐藏问题（以及什么取代了它）

过去二十年，"我怎么发布日历"的答案一直是：生成一个 ICS 文件，放在一个 URL 后面，告诉人们订阅。

它有效。从 1998 年起就一直有效。但任何真正从原始 ICS 源运营直播活动系列的人都知道隐藏的失败模式——那种不会出现直到你六个月后悔那个设置的。

下面是那些，以及广播组用什么取代它们。

问题 1：你不能编辑活动

一个原始 ICS 源通常在发布时生成——你设置 URL、推送活动、它们同步出去。当你需要改正拼写、移动时间或取消会议时，客户端必须真的重新获取源并尊重更新。

实际上：有些客户端尊重基于 UID 的更新。有些不会，把旧活动永远留在日历上。有些只会重复。你通过邮件发现（"嘿，你的晚上 7 点对我显示了两次"），没有好答案。

广播组正确管理活动 UID 和更新。编辑是编辑。取消是取消。源是版本化的。

在原始 ICS 源，每个订阅者看到每个活动。如果有人喜欢这个系列但下周二来不了，他们的唯一选择是：手动删除活动（然后它在下一次同步时会回来），或从整个源取消订阅。

两个选择都不好。第一个令人困惑。第二个为了一个冲突失去了一个订阅者。

广播组支持单活动退出。订阅者点一个链接，那个活动只从他们的源消失，系列的其他保留不变。

一个静态 ICS URL 是一个网络服务器服务的文件。如果你看访问日志你能估计，但大多数活动组织者不会。你不知道你有 10 个订阅者还是 10,000 个。

广播组给你一个匿名订阅者数字——没有邮箱，没有身份，只是"这个活动在多少个日历上"。仅这个数字就改变了你怎样运营这个系列。

Google Calendar 以自己的节奏刷新外部 ICS 源而著名——有时是每天，有时更慢。Apple Calendar 更快但不是即时。Outlook 是……Outlook。

这不是你能从源方面修复的；应用控制刷新。但用一个包含单活动 iCalendar VEVENT 更新和恰当序列号的广播源，发生的刷新会正确传播。用一个手工制作的 ICS，通常不会。

一个 ICS 源，一旦订阅，在订阅者记得怎么移除它前保留在他们的日历上。大多数应用把那个 UI 隐藏五菜单深。从组织者方面，没有办法取消某个报告滥用的人，没有办法在不破坏每个人源的情况下撤销单一订阅。

广播组在订阅者体验中有一键取消订阅，如果出错组织者能重新生成分享链接。

ICS 源做得好的所有东西——匿名、通用、单向、离线可用、无需登录——广播组保留。底层传输仍然是 iCalendar；每个日历应用已经知道怎么读它。改变的是周围的操作层：编辑、退出、计数、撤销。

如果你发布一个定期活动系列并且你曾经得答过一个"活动从我的日历消失了"邮件，这就是升级路径。